Сбои и доступность
PHP-FPM достиг pm.max_children: почему запросы ждут
PHP-FPM сообщает о достижении pm.max_children, а запросы ждут. Объясняем ограничение числа обработчиков и порядок проверки перед его увеличением.
Что происходит и с чего начать
PHP-FPM обслуживает запросы ограниченным числом процессов. Когда все допустимые обработчики заняты, следующие обращения могут ждать освобождения. Параметр pm.max_children задаёт соответствующий предел, но его достижение само по себе не объясняет, почему процессы заняты. Причиной бывает обычный рост трафика, тяжёлый код или длительное ожидание внешнего ресурса. Поэтому сначала нужно измерить работу запросов и память процессов. Простое увеличение числа обработчиков способно исчерпать память сервера и сделать отказ ещё тяжелее.
Что можно проверить самостоятельно
- Сохраните время предупреждения и связанные ошибки посетителей. Уточните, какие страницы или действия выполнялись в этот период и был ли необычный рост одновременных обращений.
- Посмотрите графики памяти и процессора, если они доступны. Сообщите о совпадающих обменах, отчётах и длительных запросах к внешним сервисам, а не только о количестве визитов.
- Уточните текущий предел и кто управляет конфигурацией PHP-FPM. Не копируйте большое значение с другого сервера: объём памяти одного процесса и соседние службы отличаются.
Как понять результаты проверки
Администратор оценивает ресурсы одного обработчика и всей системы, разработчик ищет запросы, которые удерживают процессы. Важен резерв для базы и других служб. Если часть работы можно вынести в фон или ограничить ожидание внешнего API, это рассматривают отдельно. Но фоновые операции тоже требуют контроля нагрузки. Обоснованное решение показывает, почему выбранный предел соответствует серверу и как уменьшена стоимость медленных запросов. Оно не сводится к исчезновению предупреждения при неизвестном расходе памяти.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Сопоставьте предупреждение с очередью запросов и временем ответа. Проверьте, относится ли оно к нужному пулу сайта.
- Оцените потребление памяти процессами при реальных действиях. Оставьте ресурсы базе, операционной системе и другим службам.
- Изучите медленные запросы PHP: внешние API, блокировки базы и долгие вычисления. Процесс может быть занят ожиданием, почти не используя CPU.
На что обратить внимание
Слишком маленький пул ограничивает пропускную способность, но слишком большой способен вызвать нехватку памяти. Без измерения длительности запросов увеличение лимита лишь откладывает насыщение.
Как исправляют причину
Устраните длительные ожидания и настройте размер пула по ресурсам. Проверьте параметры управления процессами и ограничения остальных зависимостей. Страницу статуса пула держите закрытой от внешних посетителей.
Как убедиться, что проблема решена
Под контролируемой нагрузкой сравните длину очереди, память, ошибки и задержки. Проверьте восстановление после пика: процессы не должны уходить в постоянные перезапуски.
После изменения повторите сопоставимую нагрузку и проверьте время ожидания, ошибки и память. Убедитесь, что сервер не начал завершать процессы из-за нехватки ресурсов. Если причина была в медленной зависимости, проверьте её отказ отдельно. Приёмка должна подтверждать стабильную работу нужных действий, а не только отсутствие строки pm.max_children в коротком периоде без реальных посетителей.