208 похожих чатов

Коллеги. Добрые день/утро/вечер. Есть задачка в БУС, работающая на кроне, принцип

примерно такой:

$resElements = CIBlockElement::GetList(...);
while ($arElement = $resElements->GetNext()) {
// тут мы получаем через curl и парсим цены с соседнего сайта, потому процедура не быстрая и длиться // несколько часов
CCatalogProduct::Update(...);
CIBlockElement::SetPropertyValuesEx(...);
}

проблема в том, что не всегда, но часто в процессе работы, на хостинге OM-KILLER убивает MySQL как самого прожорливого по памяти и всё падает. Да, знаю, правильный вариант это увеличить память и сделать SWAP (заказчику я уже высказал своё замечание по поводу создания машины без свопа).
Однако заинтересовался вопросом, а можно ли такое перехватить и подождать, пока MySQL снова не запуститься, а он потом снова стартует, буквально секунд через 5-10, и продолжить работу. На сях в свое время я так и писал, но там я напрямую работал с БД, как был отвал (по факту ни разу не случалось), просто sleep и реконект к базе. А вот на битриксе, возможен ли такой фокус?

3 ответов

13 просмотров

1. OOM-killer вроде как приходит когда память на сервере заканчивается, а обычно это происходит когда неправильно подобраны параметры - посчитайте сколько есть один процесс php, посмотрите на сколько процессов сконфигурирован httpd, прибавьте сопутствующее ПО, потом прибавьте количество соединений (там вроде как в идеале 1 соединению httpd должно быть 1 mysql) и посмотрите сколько памяти. Скорее всего когда сложите получиться что требуется больше оперативы чем у вас есть. 2. Что касается решения "здесь и сейчас", то можно действовать по-другому - добавьте постраничку. Т.е. поймайте количество элементов и запустите цикл по Н записей, на каждом круге которого будете получать и обрабатывать запрос в БП. Это несколько сократит потребление. Сейчас у вас mysql может подвисать на "Sending data". А вообще можно разрезать на потоки такую штуку и тоже очень неплохо пойдет.

Вячеслав-Трофимов Автор вопроса
Andrei Nikolaev
1. OOM-killer вроде как приходит когда память на с...

За идею по постраничке спасибо, не подумал и переписывать немного, т.к. заказчик сказал все решения по минимуму в часах, либо за спасибо :) Хотя мне кажется не спасёт, я в логах видел там MySQL киляется периодически, а мой скрипт работает раз в неделю, просто иногда этот момент приходится на время его работы. А вот все-таки, продолжение работы после перезапуска MySQL возможно? например, подключить epilog, который вроде как закрывает соединение и потом снова пролог, прокатит? (если конечно перехват аварийного завершения в глубине ядра битрикса вообще возможен)

Вячеслав Трофимов
За идею по постраничке спасибо, не подумал и переп...

Не думаю что это возможно без совсем уж черной магии. Проще в таком случае на очереди первести или потюнить

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта