PHP-FPM LinuxPHP 8.xNginx/Apache

PHP-FPM: медленный сайт задерживает запросы других пулов

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

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

Разделение на пулы защищает конфигурации процессов, но не гарантирует независимых ресурсов: все пулы могут делить CPU, RAM, дисковую подсистему и один MySQL. В ряде установок действует глобальный process.max.

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

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

Один сайт на сервере начинает выполнять тяжёлые запросы, и страницы других сайтов тоже замедляются, хотя они используют разные пулы PHP-FPM. Ищем общие ресурсы, ограничения CPU и памяти, глобальный process.max и взаимное влияние базы данных. Разделение на пулы защищает конфигурации процессов, но не гарантирует независимых ресурсов: все пулы могут делить CPU, RAM, дисковую подсистему и один MySQL. В ряде установок действует глобальный process.max.

Возможная причинаКак узнатьЧто делать
Общая нагрузка CPU или памятьОдин пул запускает много тяжёлых обработчиков и вытесняет остальные процессы или вызывает подкачку.Одновременно растут нагрузка CPU, swap и время отклика независимых сайтов.Оценить процессы, ограничить тяжёлые задания и оптимизировать код.
Общий MySQL либо дискНесколько сайтов ждут один сервер БД и медленные операции ввода-вывода.В PHP других сайтов ожидание SQL; в системе повышенная дисковая задержка.Установить конкретные медленные запросы и их владельца.
Общий глобальный лимит и отсутствие изоляцииprocess.max в главной конфигурации ограничивает общее число процессов FPM, либо разные пулы на самом деле обслуживают один сокет.При росте нагрузки один пул перестаёт порождать процессы другого, хотя локальные лимиты не достигнуты.Проверить главный конфиг, сокеты и распределение ресурсов.

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

  1. Определите совпадающее время задержки двух независимых сайтовВ браузере откройте проблемную и контрольную страницы на каждом домене, запишите время начала и среднюю задержку нескольких запросов. Не запускайте нагрузочное тестирование в часы пик. Проверьте журналы доступа обеих виртуальных площадок, чтобы убедиться, что замедление синхронно и не объясняется сторонними изображениями. В отчёте оставляйте только адреса без токенов и персональных параметров.
  1. Проверьте изоляцию пулов и их реальные сокетыВ панели хостинга откройте параметры PHP каждого сайта и найдите назначенный пул или обработчик. Если есть SSH, сравните fastcgi_pass двух сайтов с директивами listen каждого пула. Разные имена пользователей сами по себе не означают разные пулы. Если оба домена используют один и тот же сокет, сначала исправьте их привязку в панели; конфигурационные изменения делайте с копией и тестом, а не вручную переносите файлы сокетов.
  1. Снимите системные показатели в момент ухудшенияПодключитесь по SSH в терминале своего компьютера и на сервере запустите uptime, free -h и ps -eo pid,ppid,rss,pcpu,cmd --sort=-pcpu | head -n 25. uptime покажет среднюю загрузку, available — резерв RAM, pcpu — загрузку CPU конкретным процессом. Найдите имя пула в командах работников; если CPU высок именно у одного сайта, это важнее, чем общее число PHP-процессов. Все команды просмотровые.
    Linux · Терминал (Bash)Команда
    Только для просмотра. Данные ps моментальные, при коротких пиках повторите вручную позже.
    uptime
    free -h
    ps -eo pid,ppid,rss,pcpu,cmd --sort=-pcpu | head -n 25
  1. Ищите общие зависимые службыВ журнале медленных запросов или трассировке приложения проверьте, не заняты ли процессы ожиданием MySQL, Redis, сети или файловой системы. Если сайт с низким трафиком тоже ждёт БД, диагностику нужно продолжить на стороне MySQL (время запросов и блокировки). Не останавливайте БД и не меняйте её общие пределы до резервного копирования и уточнения причин.
  1. Узнайте, существует ли общий лимит process.maxИзучите главный php-fpm.conf именно той службы, где работают оба пула; параметр process.max ограничивает общее число дочерних процессов FPM и по умолчанию часто равен 0 (нет общего лимита). Отдельно запишите pm.max_children каждого пула. Если лимит уже установлен, посмотрите предупреждения основного журнала и вычислите суммарную ожидаемую потребность; не меняйте его без оценки физической памяти и резервов системы.
  1. Снизьте влияние тяжёлой задачи в одном пулеСначала перенесите пакетные операции, создание архивов и массовый импорт на ограниченную фоновую очередь с контролем одновременности. Если виновник — медленный SQL-запрос, исправьте индекс или уменьшите объём данных после анализа плана выполнения. Для отдельного пула можно рассмотреть уменьшение pm.max_children, но это повышает задержки его собственных клиентов; пробуйте изменение только при замерах и согласованном лимите ресурсов.
  1. При необходимости задайте безопасные пределы по пуламСделайте копии файлов обоих пулов и их главного php-fpm.conf. Рассчитайте допустимый бюджет RAM и CPU для всех сайтов, а не только виновника. В режиме dynamic согласуйте pm.start_servers, pm.min_spare_servers, pm.max_spare_servers с новым pm.max_children; не ставьте малые значения другим сайтам произвольно. Если нужна настоящая изоляция от соседей по CPU и памяти, используйте ресурсы systemd/контейнеров под контролем администратора.
  1. Проверьте конфигурацию и сравните ответы обоих доменовДля стандартного PHP 8.2 на Debian после правки выполните sudo php-fpm8.2 -t. При успешном результате примените sudo systemctl reload php8.2-fpm; иначе верните конфигурационные копии. Повторите обычные пользовательские действия на обоих сайтах при аналогичной нагрузке, отслеживая CPU, доступную память и журналы FPM. Если один сайт снова мешает другому, восстановите старые лимиты и передайте администратору замеры общих зависимых служб.
    Linux · Терминал (Bash)С осторожностьюНужен sudo
    Пример для Debian с PHP 8.2; замените версию на действующую. Выполнить вторую команду только после успешной проверки, с правами администратора. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.
    sudo php-fpm8.2 -t && sudo systemctl reload php8.2-fpm

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

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

Успех — рост нагрузки на первом сайте не увеличивает заметно время отклика второго, в обоих пулах нет роста очереди и система сохраняет резерв CPU/RAM. Сравнивайте один и тот же набор страниц и сопоставимую активность. Если задержки продолжаются, проверяйте общую базу и файловую систему и откатывайте только изменённые параметры.

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

PHP-FPM: server reached pm.max_children setting — причины и решение Предупреждение PHP-FPM «server reached pm.max_children setting» означает, что все процессы заняты. Рассчитайте max_children по памяти, найдите долгие запросы через slowl… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: как рассчитать pm.max_children по памяти — причины и решение Предупреждение pm.max_children reached в PHP-FPM означает исчерпание пула процессов. Рассчитайте max_children по доступной памяти и среднему размеру процесса, выберите р… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: запросы выполняются медленно, в логе slowlog — причины и решение Медленные запросы и таймауты в PHP-FPM (502/504) исправляются включением slowlog, настройкой request_terminate_timeout, fastcgi_read_timeout в nginx, оптимизацией запрос… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: connect() to unix socket failed (13: Permission denied) — причины и решение Ошибка «connect() to unix:/run/php/php-fpm.sock failed (13: Permission denied)» исправляется настройкой listen.owner, listen.group и listen.mode в пуле PHP-FPM под польз… Сайты, серверы и хостинг PHP-FPM Linux PHP-FPM: server reached pm.max_children и ответы 503/504 — причины и решение Предупреждение значит, что все процессы заняты. Найдите медленные запросы, увеличьте max_children при наличии памяти и включите кэширование. Сайты, серверы и хостинг PHP-FPM Linux

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

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