PHP-FPM LinuxPHP 8.xNginx/Apache

PHP-FPM: reached pm.max_children при резком росте одновременных запросов

  • Обновлено
  • Чтение ≈ 5 минут
  • Нужны права администратора

Краткий ответ

Этот сценарий касается кратковременного роста одновременных запросов, а не просто общего подбора параметра pm.max_children. Само предупреждение не доказывает недостаток выделенных процессов: их может надолго занимать медленный SQL, внешний API или массовый обход сайта.

В этой статье
  1. Симптомы и отличие от похожих неисправностей
  2. Диагностика и пошаговое устранение
  3. Как проверить результат и что предпринять при неуспехе

#Симптомы и отличие от похожих неисправностей

В журнале PHP-FPM появилось предупреждение «server reached pm.max_children setting», а страницы стали открываться медленно именно во время всплеска одновременных обращений. Пошаговая диагностика с учётом памяти, журналов запросов и очереди. Этот сценарий касается кратковременного роста одновременных запросов, а не просто общего подбора параметра pm.max_children. Само предупреждение не доказывает недостаток выделенных процессов: их может надолго занимать медленный SQL, внешний API или массовый обход сайта.

Возможная причинаКак узнатьЧто делать
Временный всплеск параллельных запросовВ момент рекламного перехода, сканирования или загрузки медиа одновременных PHP-запросов становится больше, чем свободных работников пула.Запись о достижении лимита совпадает по минутам со скачком обращений и ростом очереди.Сопоставить события в журналах и оценить нормальную нагрузку.
Медленные обращения удерживают работниковНебольшое число запросов к базе данных или внешнему сервису выполняется слишком долго и блокирует остальные.В журнале slowlog или трассировке виден один и тот же долгий участок; поток посетителей не вырос.Устранить зависание раньше увеличения числа процессов.
Лимит не соответствует безопасной памятиУ пула мало работников относительно трафика, но слепое повышение может привести к нехватке оперативной памяти.Одновременно заняты все процессы, доступная RAM или подкачка уже близка к пределу.Измерить RSS рабочих процессов и рассчитать резерв по памяти.

#Диагностика и пошаговое устранение

  1. Зафиксируйте период всплеска и безопасно подключитесь к серверуОткройте панель хостинга → «Журналы» нужного домена либо подключитесь по SSH: на Windows откройте «Терминал» через меню «Пуск», на Linux — терминал, введите ssh пользователь@имя-сервера, заменив обе части своими данными. Откройте журнал ошибок PHP-FPM через панель или journalctl. Запишите точное время сообщения server reached pm.max_children setting и название пула в квадратных скобках. Если сообщения нет, уточните, какой PHP-FPM реально обслуживает сайт; не увеличивайте лимит наугад.
    Linux · Терминал (Bash)КомандаНужен sudo
    Просмотр сообщений systemd на сервере. Нужны права на системный журнал (в примере sudo); при отсутствии совпадений проверьте отдельный error_log FPM. Команда ничего не меняет.
    sudo journalctl --since '30 min ago' --no-pager | grep -F 'pm.max_children'
  1. Сравните число обращений и время ответа именно в этот моментВ панели домена откройте журнал доступа Nginx/Apache и фильтр по часу предупреждения. Посмотрите, не выросли ли резко обращения к /index.php, API, поиску, импорту или авторизации. Если журналы включают длительность ($request_time или аналог), найдите медленные страницы; если нет, сначала настройте наблюдение в закрытом тестовом периоде. Не публикуйте журналы: они могут содержать IP-адреса и токены. Отсутствие прироста обращений чаще указывает на зависшие обработчики, а не на нехватку числа процессов.
  1. Снимите состояние сервера до изменения настроекПо SSH выполните free -h, затем ps -eo pid,rss,cmd --sort=-rss | head -n 25. Первая команда показывает available — доступную память; вторая показывает самые прожорливые процессы и RSS в килобайтах. Убедитесь, что в выводе есть именно процессы этого пула PHP-FPM, а не только база данных. Если память почти кончилась, прекратите попытки увеличить pm.max_children: новые процессы могут вызвать завершение сервисов системой.
    Linux · Терминал (Bash)Команда
    Две команды только для просмотра на Linux через SSH. rss — физическая память процесса в КиБ; суммирование общей памяти по RSS неточно из-за разделяемых страниц.
    free -h
    ps -eo pid,rss,cmd --sort=-rss | head -n 25
  1. Проверьте статус пула и загрузку очереди, если доступ разрешёнЕсли в пуле уже настроены pm.status_path и доступ с localhost, откройте статус только из закрытого административного канала. Найдите active processes, idle processes, max children reached, listen queue и max listen queue. Если статус недоступен, не делайте его публичным ради диагностики. Рост очереди вместе с постоянно занятыми процессами подтверждает ограничение обслуживающей мощности, но не объясняет источник длительных запросов.
  1. Найдите медленный запрос до изменения лимитаСопоставьте минуты всплеска с журналом долгих запросов PHP-FPM (slowlog) или с журналом приложения. В первую очередь изучите обращения к базе, резервному копированию, импорту или внешним API. Проверьте время SQL-запроса и наличие ограничения ожидания на внешнем сервисе. Если один и тот же запрос занимает десятки секунд, оптимизируйте этот участок и повторите замер при прежнем лимите; добавление процессов увеличит нагрузку на БД.
  1. Проверьте действующий пул и сохраните его конфигурациюУточните у панели или администратора путь к пулу: часто это /etc/php/8.2/fpm/pool.d/имя.conf, но Fastpanel и отдельные версии PHP используют другие каталоги. Запишите текущие pm, pm.max_children, pm.start_servers, pm.min_spare_servers и pm.max_spare_servers. Сохраните копию именно этого файла через панель или администратором сервера. В режиме dynamic значения start/min/max_spare должны быть согласованы с pm.max_children; в ondemand они не применяются.
  1. Увеличивайте предел только после расчёта свободной памятиЕсли подтверждён кратковременный честный спрос и есть запас ОЗУ, рассчитайте безопасный предел: выделенная пулу память / типичный RSS одного загруженного работника, оставив резерв ОС, MySQL, Nginx и других пулов. Например, при 2 ГиБ свободного бюджета пула и 100 МиБ на работника верхняя оценка — около 20, но измерения и общие страницы памяти делают расчёт приблизительным. Изменяйте pm.max_children постепенно через панель или конфигурацию пула, не ставьте сотни процессов просто по числу посетителей.
  2. Исключительно пример согласованных чисел, НЕ универсальные настройки
    INI
    Исключительно пример согласованных чисел, НЕ универсальные настройки. Менять только реально работающий пул после расчёта памяти.
    pm = dynamic
    pm.max_children = 20
    pm.start_servers = 4
    pm.min_spare_servers = 2
    pm.max_spare_servers = 8
  1. Протестируйте конфигурацию и примените её в согласованное окноДля Debian с PHP 8.2 сначала выполните sudo php-fpm8.2 -t, затем, только если отображается успешная проверка, sudo systemctl reload php8.2-fpm. В другой версии замените цифры на версию вашей службы; в панели управления используйте её штатный способ применения. При ошибке теста не перезагружайте процесс, восстановите резервный файл и повторите проверку. На производственном сервере заранее согласуйте изменение: часть запросов может выполняться в момент перезагрузки.
    Linux · Терминал (Bash)С осторожностьюНужен sudo
    Пример для стандартной установки Debian PHP 8.2. Замените бинарник и название службы согласно вашей версии; вторую команду запускать ТОЛЬКО после успешной первой. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.
    sudo php-fpm8.2 -t && sudo systemctl reload php8.2-fpm

    Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

  1. Проверьте во время следующего пика и при необходимости отмените изменениеПовторите безопасный тест исходной страницы и сравните время ответа, listen queue, предупреждения pm.max_children и доступную память до и после. Успех — стабильная скорость без роста очереди и давления на ОЗУ при сопоставимой нагрузке. Если возникли ошибки 502/504, OOM или лавина SQL-запросов, верните исходное значение из копии, выполните тест конфигурации и reload, затем передайте разработчику конкретные URL, время и сведения о медленных запросах.

#Как проверить результат и что предпринять при неуспехе

В течение сопоставимого пика не должно появляться повторных сообщений reached pm.max_children, очередь не должна накапливаться, а RAM должна сохранять резерв. При сохранении задержек проверьте запросы к БД, внешний API и наличие других насыщенных пулов. Фиксируйте нагрузку до/после, поскольку единичная проверка в спокойный час не подтверждает исправление.

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.