Назад | Перейти на главную страницу

php-fpm вызвал oom-killer

Я вижу проблему, при которой PHP-FPM отлично работает в течение нескольких дней, а затем решает заполнить всю память + подкачку и вызвать OOM-Killer. После этого сервер полностью мертв, и вы больше не можете подключиться к нему по SSH. Чтобы вернуть все в норму, должен произойти жесткий перезапуск.

Мне интересно, почему это происходит, и есть ли исправление или обходной путь, например ограничение объема памяти, которое он может использовать, или перезапуск процесса, если он начинает использовать слишком много.

Я захватил дампы ядра несколько раз, когда это происходило.

  1. http://pastebin.com/raw.php?i=rX6jYDe0
  2. http://pastebin.com/raw.php?i=f2qx5GcS

Мой php-fpm.conf

  1. http://pastebin.com/raw.php?i=27hvN27q

Мой www.conf:

  1. http://pastebin.com/raw.php?i=VgYtut9j

Дайте мне знать, если я могу еще что-нибудь дать вам для получения дополнительной информации о том, почему это может происходить.

Об OOM можно найти много полезной информации. Если вы хотите понять, что происходит, я рекомендую поискать это по еще нескольким ключевым словам вроде этого

У меня у самого было такое однажды в проекте клиента, и мне пришлось позаботиться об этом. К сожалению, ни одно из приведенных выше рекомендаций не помогло, так как это связано с ядром. OOM - это грязный обходной путь для чрезмерного использования памяти в Linux.

Что помогло (мне), так это установка некоторых параметров ядра, которые полностью избегают OOM. Чтобы быстро исправить это, добавьте следующие строки в /etc/sysctl.conf чтобы изменение сохранялось при загрузке:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

Однако я бы порекомендовал прочитать OOM. Вы можете найти более полезную информацию об этом.

Попробуйте уменьшить pm.max_requests до более низких значений (1000). Кроме того, у вас высокие значения pm.start_servers, pm.start_servers, pm.max_spare_servers и чрезвычайно высокие значения pm.max_children

Возможно, вам потребуется выяснить, вызвано ли выделение всей памяти одним необычным запросом (в этом случае вам придется исправить код) или это результат прогрессирующей утечки памяти. В последнем случае можно уменьшить max_requests параметр для более частого перезапуска потомков PHP-FPM.

Если вы не можете исправить проблему в коде, возможно, вам придется использовать грязный хакер. Например, напишите скрипт, который будет отслеживать потребление памяти PHP и перезапустить его.

Также есть способ ограничить потребление памяти для данного процесса (как описано Вот или Вот), но у меня не было возможности проверить это.