#Симптомы и отличие от похожих неисправностей
В журнале PHP-FPM появилось предупреждение «server reached pm.max_children setting», а страницы стали открываться медленно именно во время всплеска одновременных обращений. Пошаговая диагностика с учётом памяти, журналов запросов и очереди. Этот сценарий касается кратковременного роста одновременных запросов, а не просто общего подбора параметра pm.max_children. Само предупреждение не доказывает недостаток выделенных процессов: их может надолго занимать медленный SQL, внешний API или массовый обход сайта.
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Временный всплеск параллельных запросовВ момент рекламного перехода, сканирования или загрузки медиа одновременных PHP-запросов становится больше, чем свободных работников пула. | Запись о достижении лимита совпадает по минутам со скачком обращений и ростом очереди. | Сопоставить события в журналах и оценить нормальную нагрузку. |
| Медленные обращения удерживают работниковНебольшое число запросов к базе данных или внешнему сервису выполняется слишком долго и блокирует остальные. | В журнале slowlog или трассировке виден один и тот же долгий участок; поток посетителей не вырос. | Устранить зависание раньше увеличения числа процессов. |
| Лимит не соответствует безопасной памятиУ пула мало работников относительно трафика, но слепое повышение может привести к нехватке оперативной памяти. | Одновременно заняты все процессы, доступная RAM или подкачка уже близка к пределу. | Измерить RSS рабочих процессов и рассчитать резерв по памяти. |
#Диагностика и пошаговое устранение
- Зафиксируйте период всплеска и безопасно подключитесь к серверуОткройте панель хостинга → «Журналы» нужного домена либо подключитесь по 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'
- Сравните число обращений и время ответа именно в этот моментВ панели домена откройте журнал доступа Nginx/Apache и фильтр по часу предупреждения. Посмотрите, не выросли ли резко обращения к
/index.php, API, поиску, импорту или авторизации. Если журналы включают длительность ($request_timeили аналог), найдите медленные страницы; если нет, сначала настройте наблюдение в закрытом тестовом периоде. Не публикуйте журналы: они могут содержать IP-адреса и токены. Отсутствие прироста обращений чаще указывает на зависшие обработчики, а не на нехватку числа процессов.
- Снимите состояние сервера до изменения настроекПо 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 -hps -eo pid,rss,cmd --sort=-rss | head -n 25
- Проверьте статус пула и загрузку очереди, если доступ разрешёнЕсли в пуле уже настроены
pm.status_pathи доступ с localhost, откройте статус только из закрытого административного канала. Найдитеactive processes,idle processes,max children reached,listen queueиmax listen queue. Если статус недоступен, не делайте его публичным ради диагностики. Рост очереди вместе с постоянно занятыми процессами подтверждает ограничение обслуживающей мощности, но не объясняет источник длительных запросов.
- Найдите медленный запрос до изменения лимитаСопоставьте минуты всплеска с журналом долгих запросов PHP-FPM (
slowlog) или с журналом приложения. В первую очередь изучите обращения к базе, резервному копированию, импорту или внешним API. Проверьте время SQL-запроса и наличие ограничения ожидания на внешнем сервисе. Если один и тот же запрос занимает десятки секунд, оптимизируйте этот участок и повторите замер при прежнем лимите; добавление процессов увеличит нагрузку на БД.
- Проверьте действующий пул и сохраните его конфигурациюУточните у панели или администратора путь к пулу: часто это
/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они не применяются.
- Увеличивайте предел только после расчёта свободной памятиЕсли подтверждён кратковременный честный спрос и есть запас ОЗУ, рассчитайте безопасный предел: выделенная пулу память / типичный RSS одного загруженного работника, оставив резерв ОС, MySQL, Nginx и других пулов. Например, при 2 ГиБ свободного бюджета пула и 100 МиБ на работника верхняя оценка — около 20, но измерения и общие страницы памяти делают расчёт приблизительным. Изменяйте
pm.max_childrenпостепенно через панель или конфигурацию пула, не ставьте сотни процессов просто по числу посетителей. - Исключительно пример согласованных чисел, НЕ универсальные настройкиINIИсключительно пример согласованных чисел, НЕ универсальные настройки. Менять только реально работающий пул после расчёта памяти.
pm = dynamic pm.max_children = 20 pm.start_servers = 4 pm.min_spare_servers = 2 pm.max_spare_servers = 8
- Протестируйте конфигурацию и примените её в согласованное окноДля 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Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- Проверьте во время следующего пика и при необходимости отмените изменениеПовторите безопасный тест исходной страницы и сравните время ответа,
listen queue, предупрежденияpm.max_childrenи доступную память до и после. Успех — стабильная скорость без роста очереди и давления на ОЗУ при сопоставимой нагрузке. Если возникли ошибки 502/504, OOM или лавина SQL-запросов, верните исходное значение из копии, выполните тест конфигурации и reload, затем передайте разработчику конкретные URL, время и сведения о медленных запросах.
#Как проверить результат и что предпринять при неуспехе
В течение сопоставимого пика не должно появляться повторных сообщений reached pm.max_children, очередь не должна накапливаться, а RAM должна сохранять резерв. При сохранении задержек проверьте запросы к БД, внешний API и наличие других насыщенных пулов. Фиксируйте нагрузку до/после, поскольку единичная проверка в спокойный час не подтверждает исправление.