Сообщение server reached pm.max_children означает, что пул PHP-FPM достиг заданного предела обработчиков. Это повод проверить насыщение пула, но не доказательство, что очередь сохраняется сейчас или серверу обязательно нужна дополнительная память.
Чтобы подтвердить очередь запросов, сопоставьте предупреждение с текущими listen queue, числом свободных и занятых процессов, временем ответа сайта и логами за один интервал. Затем выясните, что удерживает обработчики: поток запросов, медленный код, база данных или внешний сервис.
1. Найдите нужный пул и время события
PHP-FPM выполняет PHP-запросы в рабочих процессах. Параметр pm.max_children ограничивает их число и тем самым параллельную обработку запросов; детали режимов static, dynamic и ondemand описаны в документации PHP-FPM.
Проверьте, в какой пул веб-сервер передаёт проблемный URL: сопоставьте FastCGI-сокет или порт с listen в конфигурации FPM. На сервере может быть несколько версий PHP и пулов: изменение чужого пула не затронет сайт.
Зафиксируйте время с часовым поясом, имя пула, действующий лимит и режим управления процессами. Сверьте их с предупреждениями FPM, ошибками upstream и длительностью запросов веб-сервера. Один код 504 не определяет, на каком участке возникло ожидание.
2. Подтвердите ожидание свободного обработчика
Если status page FPM уже настроена, снимите несколько показаний во время замедления и после него. Она должна быть доступна только администратору из доверенной сети: полный вывод может раскрывать пути скриптов и адреса запросов.
Читайте поля вместе:
listen queue— запросы, которые сейчас ждут свободный процесс;idle processesиactive processes— свободные и занятые обработчики;max listen queue— наибольшая замеченная очередь;max children reached— признак достижения предела с момента запуска пула;start time— точка отсчёта этих показателей.
Определения и границы счётчиков приведены в справке status page. Исторический максимум не показывает текущую очередь, а после перезапуска пула статистика сбрасывается.
Убедительная картина насыщения: очередь положительна в повторных замерах, свободных процессов нет, а занятые достигают настроенного предела. Совпадение с ростом времени ответа связывает насыщение с жалобами, но ещё не объясняет его причину.
Если очередь уже нулевая, сохраните исторические значения и ищите совпадение по времени в логах. Если status endpoint обслуживает тот же занятый пул, он тоже может ждать; отдельный pm.status_listen рассматривают с учётом поддержки установленной версии и ограничений доступа.
3. Выясните, чем заняты процессы
Низкая загрузка CPU не исключает насыщение: обработчик может ждать SQL, сеть или блокировку. Сравните частоту входящих запросов, их длительность и ресурсы именно в проблемный интервал.
Запросов стало больше
По access log найдите маршруты, у которых вырос поток, и проверьте, дошли ли они до PHP. Например, после очистки кеша больше запросов может попасть в приложение, хотя посещаемость почти не изменилась.
Не определяйте вредоносный трафик по одному объёму. Сначала отделите полезные обращения от повторов интеграции, фонового опроса и запросов, которые можно обслуживать кешем.
Запросы стали выполняться дольше
Найдите медленные маршруты по журналам FPM и приложения. Если имеющихся данных мало, администратор может временно настроить slowlog и request_slowlog_timeout: они помогают получить стек долгого выполнения, а не ускоряют запрос.
Сопоставьте стек с медленными SQL, ожиданием блокировок и тайм-аутами внешних API. Slowlog не измеряет очередь до начала обработки в PHP, поэтому его нужно читать вместе со status page и логами веб-сервера.
Если последовательность видна только у одной авторизованной сессии, отдельно проверьте блокировку PHP-сессии. Такая блокировка тоже способна удерживать процессы, но требует исправления участка работы с сессией.
4. Выберите изменение по найденной причине
Увеличение pm.max_children оправдано, когда полезные запросы упираются в параллелизм и есть запас ресурсов. Оцените память процессов под рабочей нагрузкой, общий расход FPM, память базы и остальных служб, а также лимит контейнера, если он используется.
Не делите всю RAM на один случайный RSS и не принимайте memory_limit за фактический расход процесса. Общие страницы памяти и разная тяжесть маршрутов делают такую оценку неточной; нужен запас и проверка на характерной нагрузке.
- Если упёрлись в CPU или память, дополнительные процессы могут усилить конкуренцию.
- Если процессы ждут БД или API, сначала разберите запросы, блокировки и сетевые ожидания.
- Если пул ограничен при свободных ресурсах, меняйте лимит постепенно, контролируя очередь и время ответа.
- Если тяжёлая операция не обязана завершаться в HTTP-запросе, оцените её перенос в фоновую очередь.
Увеличение backlog позволяет дольше ждать, но не добавляет скорости обработки. Повышение тайм-аутов также не устраняет причину: посетитель может просто дольше ждать тот же результат.
5. Проверьте результат на том же сценарии
До применения конфигурации сохраните прежние значения и проверьте синтаксис штатной командой установленной версии FPM. После изменения повторите безопасный сценарий без создания реальных заказов или повторной оплаты.
При сопоставимой нагрузке очередь должна успевать разгружаться, время ответа — вернуться к обычному уровню, а ошибки — прекратиться без роста swap и отказов по памяти.
Внешний мониторинг Web-Puls помогает сопоставить HTTP-ошибки и задержки публичного URL со временем события, но сам по себе не читает очередь FPM и не устанавливает причину насыщения.
Если очередь повторяется, а источник ожидания неясен, отправьте заявку на диагностику. Укажите публичный URL, время и часовой пояс, имя пула, лимит, обезличенные показатели очереди и последние изменения; не передавайте пароли, Cookie и сырые пользовательские запросы. Команда уточнит задачу и согласует формат и стоимость до начала работ.