#Симптом и границы применимости
При реальном росте нагрузки конкретный пул PHP-FPM достигает pm.max_children и новые запросы вынуждены ждать. Значение задаёт число одновременно обрабатываемых запросов в этом пуле; слишком большое значение способно вызвать нехватку памяти, а простое увеличение лимита не исправит зависший PHP-код.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Запросы выполняются слишком долгоКаждый долгий запрос удерживает одно место в пуле. | При загрузке видны медленные обращения и занятые дочерние процессы | Измерить время запроса и работу с БД |
| Лимит слишком мал для измеренной памятиНастройки определяют максимум процессов, но каждый расходует память. | В журнале server reached pm.max_children | Оценить безопасную ёмкость пула по RSS/PSS |
| В сервере несколько пуловОбщий объём памяти должен учитывать все пулы и другие службы. | Один пул исчерпан, соседние работают нормально | Проверить настройки и загрузку каждого отдельно |
#Пошаговая диагностика и исправление
- Зафиксируйте факты, а не только HTTP 504В SSH выберите службу обслуживающего домен пула. Просмотрите её журнал за момент нагрузки и найдите предупреждение server reached pm.max_children, а также время медленных запросов. Не считайте любой 502/504 доказательством этого лимита.
- Пример сервиса, измените под установленную версию; только чтениеLinux · Терминал (Bash)КомандаНужен sudoПример сервиса, измените под установленную версию; только чтение.
sudo journalctl -u php8.2-fpm --since "20 minutes ago" --no-pager | grep -Ei "max_children|slow|error"
- Посмотрите настройку именно этого пулаВ панели либо конфигурации выбранного пула узнайте pm (dynamic, ondemand, static), pm.max_children и связанные параметры. Для dynamic учитываются start_servers/min_spare_servers/max_spare_servers, для ondemand — process_idle_timeout. Не редактируйте все пулы сразу.
- Оцените расход оперативной памятиВо время типичной нагрузки выполните free -h и ps, затем по нескольким PHP-процессам оцените память (RSS включает общие страницы, поэтому простая сумма RSS завышает расход; при наличии smem полезнее PSS). Учитывайте MySQL, веб-сервер, ядро, файловый кэш и другие пулы. Не выбирайте лимит, превышающий запас RAM.Linux · Терминал (Bash)Команда
free -h; ps -eo pid,rss,cmd --sort=-rss | grep -E "php-fpm|PID" | head -n 20
- Определите источник долгих запросовВключайте slowlog точечно в нужном пуле после оценки объёма данных и прав доступа; запросы с зависшей БД, внешним HTTP или блокировкой должны быть оптимизированы. Не записывайте приватные параметры в публичный журнал. Если приложение не выдерживает поток, нужен кэш или очередь, а не бесконечное число детей.
- Выберите безопасное изменение и сохраните копиюПри подтверждённом запасе памяти скорректируйте pm.max_children на небольшую величину, например с 8 до 10, но только если измерения допускают это и суммарная нагрузка учтена. Проверьте требования динамического pm к spare/start, синтаксис FPM и перезапускайте только изменённую службу в согласованное окно.
- Дополнительная команда по темеLinux · Терминал (Bash)С осторожностьюНужен sudoДля Debian с PHP 8.2; замените исполняемый файл нужной версии, используйте резервную копию.
sudo php-fpm8.2 -tКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- Оцените эффект на нормальном трафикеВ течение обычного периода нагрузки сравните частоту предупреждений, время PHP-ответа, свободную память и отсутствие OOM. Не проводите неконтролируемые нагрузочные тесты на действующем сайте. Если память упала и появились сбои других сайтов, верните прежнее pm.max_children.
#Как проверить результат
Пул обслуживает реальную нагрузку без очередей и сообщений reached pm.max_children при достаточном запасе RAM; соседние пулы и БД остаются стабильны.
#Если проблема не устранена
Если предупреждение возвращается даже после разумной настройки, найдите медленный запрос, блокировки БД или внешнюю службу. Увеличение лимита при нехватке памяти способно ухудшить отказ.