Последние три ночи подряд у меня запускался сервер EC2, который выдавал 408 ошибок в ответ на веб-запросы. Когда я прихожу утром, я не могу войти по ssh; Мне нужно перезагрузиться с помощью консоли управления. И dhclient, и sshd выдают сообщения об ошибках, в которых говорится: «fork: не удается выделить память».
Насколько я могу судить, это происходит только с одним сервером. Детали каждый раз немного отличались:
В первую ночь это произошло около 19:30 (согласно / var / log / messages), но сообщение «привязано к» все еще оставалось. Затем примерно с 20:00 до 20:30 появляется много DHCPREQUEST, и после этого не происходит успешного связывания. Ошибки sshd начинаются примерно в 21:10 (согласно / var / log / secure).
На вторую ночь мы видим строки DHCPREQUEST с 18:45 до 19:15, и после этого начинается ошибка вилки. Ошибки sshd начинаются в 18:20.
На этом этапе я обновил dhclient через yum, чтобы посмотреть, поможет ли это. (На тот момент я не видел ошибок sshd.) Не было.
Третья ночь похожа на первую, с ошибкой вилки в 18:30 и запросами DHCPREQUEST с 19:00 до 19:30. Но затем в 4:15 утра входит убийца OOM и завершает процесс httpd. Убийца OOM не появлялся первые две ночи. Ошибки sshd начинаются в 19:30, а в 4:15 появляется много ошибок «Получено отключение».
Эта ветка на форумах разработчиков AWS предполагает, что dhclient может иметь утечку памяти в переменной среды, но я не вижу этого, если это так. Это тоже не похоже на медленную утечку: это происходило каждую ночь раньше, но я перезагрузил сервер в 17:00 после обновления dhclient, так что в третий раз он проработал менее двух часов.
Я рассматривал утечку памяти из apache, но, похоже, она не совпадает ни с чем конкретным в журналах apache, и мне не удалось вызвать ее, отправив на сервер несколько одновременных запросов, интенсивно использующих память. И в этом случае я ожидал, что убийца OOM был задействован все три ночи.
В журналах apache есть одна примечательная вещь: временные метки в трех последовательных строках: 24 / фев / 2017: 02: 10: 05, 23 / фев / 2017: 18: 23: 05, 24 / фев / 2017: 07 : 03: 20. Вторым из этих запросов было 500, а не 408. Итак, я предполагаю, что этот запрос каким-то образом выполнялся в течение восьми или более часов, и это могло поглощать память. Первые две ночи нет ничего подобного.
По сути, я понятия не имею, что происходит. Мой текущий план состоит в том, чтобы запустить новый сервер в той же группе размещения, вместо этого указать домен на нем и оставить оба запущенными и посмотреть, что произойдет. Но я ищу предложения, как я могу это диагностировать и исправить.
Обновить
С тех пор у меня это сработало после установки простого монитора ps / cron, как было предложено пользователем ochach. Похоже, мне действительно не хватало памяти, и виноват httpd; Я не знаю, почему убийца OOM не сбежал.
Установите инструменты мониторинга и проверьте, какой процесс требует памяти. Оттуда вы можете попытаться изолировать проблему, когда узнаете, в каком процессе произошла утечка памяти. Также проверьте dmesg на предмет того, что ядро убило oom.
Чтобы точно определить проблему, вы можете добавить «ps aux --sort -rss | head -n 10» для запуска каждую минуту и добавления в файл на неэфемерном устройстве.
Помимо этого взлома, вы можете установить отдельный мониторинг, такой как nagios, prometeus или использовать sar / sysstat.