Любопытный случай из жизни. 
У Заказчика развернут сервер с нашим приложением, назовем его App.
Вчера Заказчик пожаловался — «App ушел из процессов, пришлось ребутать». Посмотрели по логам, ничего не увидели. Почему он перестал отвечать на запросы? Мистика!
Подкрутили console.log сервера, ждем... Сегодня опять падает. Коллега порасследовал это дело и вот результат:
В логе App killed (pid 1122). Последнее сообщение в логе soap-stats от 09:05 (статистика выводится раз в полчаса). в логе /var/log/messages в 09:31 «zabbix_agentd invoked oom-killer» ... «Kill process 1122».
Вчера App умер примерно в то же время, в логе messages в 09:09 аналогичное сообщение от zabbix
Собственно, ответ такой: zabbix решает, что на машине всё плохо со свободной памятью, вызывает чистильщика (oom-killer), тот выбирает App, как самого большого потребителя памяти, и убивает его.
Соответственно, вам надо донастроить zabbix, чтобы он не трогал java-процессы app.
Злобный, злобный oom-killer!
Как локализовать такую проблему?
Наши логи отловили killed, без времени и обоснования.
Дальше гугл и системные логи.
Так что помните: логи — наше все для локализации багов! И гугл, да да!
А еще, если ваше ПО жрет много памяти и по странным причинам внезапно умирает, посмотрите, не убивает ли его кто-то типа заббкса или даже самой винды (коллеги рассказали, что бывало и такое!)
PS — добавила пост в общую копилку багов.
У Заказчика развернут сервер с нашим приложением, назовем его App.
Вчера Заказчик пожаловался — «App ушел из процессов, пришлось ребутать». Посмотрели по логам, ничего не увидели. Почему он перестал отвечать на запросы? Мистика!
Подкрутили console.log сервера, ждем... Сегодня опять падает. Коллега порасследовал это дело и вот результат:
В логе App killed (pid 1122). Последнее сообщение в логе soap-stats от 09:05 (статистика выводится раз в полчаса). в логе /var/log/messages в 09:31 «zabbix_agentd invoked oom-killer» ... «Kill process 1122».
Вчера App умер примерно в то же время, в логе messages в 09:09 аналогичное сообщение от zabbix
Собственно, ответ такой: zabbix решает, что на машине всё плохо со свободной памятью, вызывает чистильщика (oom-killer), тот выбирает App, как самого большого потребителя памяти, и убивает его.
Соответственно, вам надо донастроить zabbix, чтобы он не трогал java-процессы app.
Zabbix VS ваше ПО
Злобный, злобный oom-killer!
Как локализовать такую проблему?
Наши логи отловили killed, без времени и обоснования.
Дальше гугл и системные логи.
Так что помните: логи — наше все для локализации багов! И гугл, да да!
А еще, если ваше ПО жрет много памяти и по странным причинам внезапно умирает, посмотрите, не убивает ли его кто-то типа заббкса или даже самой винды (коллеги рассказали, что бывало и такое!)
PS — добавила пост в общую копилку багов.
Спасибо за интересный и полезный кейс.
ОтветитьУдалитьBTW, на винде видел такую ситуацию, если выключить файл подкачки. Тогда в тот момент, когда не остается свободной оперативной памяти, операционная система сама закрывает какую-либо из запущенных программ (одну из самых прожорливых).
Андрей, спасибо за пример!
УдалитьДа, коллеги рассказывали, у них такое когда-то на винде простой встречалось :)
"Подкрутили console.log" Подскажите, как его подкрутить?
ОтветитьУдалитьРазработчики не могут сходу вспомнить, что именно подкручивалось)) Ну, если информации недостаточно, начинаем логировать больше
УдалитьOOM Killer запускается ядром, заббикс не при чем.
ОтветитьУдалитьВы уверены?)
Удалить