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

PHP-FPM перестает отвечать и умирает

Я запускаю Drupal 6 с Nginx 1.5.1 и PHP-FPM (PHP 5.3.26) на одноядерном VPS объемом 1 ГБ с 3 ГБ пространства подкачки на SSD-накопителе. Я просто перешел с виртуального хостинга на этот неуправляемый VPS, потому что мой сайт становился слишком тяжелым, поэтому я все еще учусь. У меня умеренно высокий трафик, я не очень внимательно за ним слежу, но Google AdSense обычно записывает около 30 тысяч просмотров страниц в день. У меня обычно от 50 до 80 авторизованных пользователей вошли в систему и еще несколько сотен анонимных пользователей попадают в статический HTML-кеш Boost в любой момент.

У меня проблема в том, что PHP-FPM часто перестает отвечать, что приводит к ошибкам Nginx 502 или 504. Клянусь, я прочитал каждую страницу в Интернете об этой проблеме, которая кажется довольно распространенной, и я пробовал бесконечные комбинации конфигураций, и я не могу найти хорошего решения. После перезапуска Nginx и PHP-FPM сайт какое-то время работает очень быстро, а затем без предупреждения просто перестает отвечать. Я получаю белый экран, пока браузер ожидает на сервере, и примерно через 30 секунд или минуту он выдает ошибку Nginx 502 или 504. Иногда он работает нормально 2 минуты, иногда 5 минут, иногда 5 часов, но всегда заканчивается зависанием. Когда я нахожу сервер в этом состоянии, там все еще много свободной памяти (> 500 МБ или более) и нет значительного использования ЦП, управляющие и рабочие процессы PHP-FPM все еще присутствуют, и сервер по-прежнему доступен для проверки связи и может использоваться через SSH . Повторная загрузка PHP-FPM с помощью сценария инициализации снова оживляет его. Кажется, что зависания не соответствуют объему трафика, потому что я постоянно наблюдал такое поведение, когда тестировал эту конфигурацию на разрабатываемом VPS без трафика.

Я постоянно менял настройки, но окончательно не могу устранить проблему. Я установил Nginx worker равным 1. В конфигурации PHP-FPM я испробовал все три диспетчера процессов. «Динамический», безусловно, наименее надежный, стабильно вешает трубку уже через несколько минут. «Статика» тоже была ненадежной и непредсказуемой. Меньше всего багов было "по требованию", но даже это меня подводит, иногда через 12-24 часов. Но я не могу оставить сервер без присмотра, потому что PHP-FPM умирает и никогда не возвращается сам по себе. Я попытался отрегулировать значение pm.max_children с 3 до 50, особой разницы нет, но сейчас у меня оно равно 10. То же самое и для значений запасных серверов. Я также установил pm.max_requests от 30 до неограниченного, и это, похоже, не имеет значения.

Я также использовал кеширование APC и Redis, чтобы снять часть нагрузки с базы данных, но проблема PHP-FPM существует как с активированными этими механизмами, так и без них.

Согласно журналам, процессы PHP-FPM завершаются не с SIGSEGV или SIGBUS, а с SIGTERM. Я получаю много строк вроде:

WARNING: [pool www] child 3739, script '/var/www/drupal6/index.php' (request: "GET /index.php") execution timed out (38.739494 sec), terminating

и:

WARNING: [pool www] child 3738 exited on signal 15 (SIGTERM) after 50.004380 seconds from start

Я действительно нашел несколько статей, в которых рекомендуется выполнять плавную перезагрузку PHP-FPM через cron каждые несколько минут или часов, чтобы обойти эту проблему. Вот что я делал: "/etc/init.d/php-fpm reload" каждые 5 минут. Пока что свет не горит. Но это похоже на ужасный взлом. Неужели PHP-FPM настолько ненадежен? Что еще я могу сделать? Большое спасибо!

Вы пробовали другой оптимизатор или пробовали использовать apc.filter? Это действительно похоже на проблему, связанную с APC, потому что стабильность APC всегда зависит от используемого кода и конфигурации apc.

Пришел сюда через Googling, поделился некоторым опытом.

Была такая же проблема, но в Drupal 7! (извините, @michael Hampton ;-) Drupal 6 отлично работает на том же VPS (2048 МБ, 2 × 2,4 ГГц @ 60%, NGINX, APC). Drupal 7 зависает через ~ 4 часа, например, пробка или что-то в этом роде ;-) В течение 2 недель я пробую и ищу разные варианты.

Похоже, наконец, отключение APC помогло. До (APC включен) CRON в Drupal выдавал ошибку в медленном журнале. Без APC сайт кажется немного быстрее.