#Что происходит и когда применима инструкция
При пике запросов PHP-FPM может накапливать ожидающие соединения в listen queue. Это не обязательно означает нехватку мощности процессора: очередь появляется, когда обработчики заняты либо ограничены блокировками, а увеличение listen.backlog без оценки pm.max_children и причины задержки не решает проблему.
#Причины и диагностические признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Достигнут лимит дочерних обработчиковДостигнут лимит дочерних обработчиков. Показатель max children reached растёт, idle processes равно 0. | Показатель max children reached растёт, idle processes равно 0. | Сократить длительные запросы и проверить реальную память. |
| Медленные внешние ожиданияМедленные внешние ожидания. Процессы заняты БД/API, ЦП невелик, но listen queue растёт. | Процессы заняты БД/API, ЦП невелик, но listen queue растёт. | Применить slowlog и диагностику зависших зависимостей. |
| Ограничение очереди ядра или listen.backlogОграничение очереди ядра или listen.backlog. listen queue близка к listen queue len, возможны ошибки соединения к FastCGI. | listen queue близка к listen queue len, возможны ошибки соединения к FastCGI. | Проверить backlog и системный somaxconn совместно. |
#Подробная пошаговая инструкция
- Зафиксируйте нагрузку и время событияОтметьте период пика, долю 502/504 и задержку ответа. Не воспроизводите атаку на производственном сервере. Откройте графики RAM, ЦП, доступных процессов и соединений из панели или штатного мониторинга.
- Проверьте, разрешена ли локальная страница состояния FPMВ конфигурации нужного пула найдите pm.status_path; страница состояния должна быть доступна только локальному администратору, а не из интернета. Если она уже настроена, снимите значения listen queue, max listen queue, idle processes, active processes, max children reached и accepted conn на нескольких замерах.
- SSH с правами администратора, Debian/UbuntuLinux · Терминал (Bash)КомандаНужен sudoSSH с правами администратора, Debian/Ubuntu. Команда показывает настройки, но не текущие размеры очереди.
sudo grep -R -nE "^\s*(\[|listen\s*=|listen.backlog\s*=|pm\.|request_slowlog_timeout)" /etc/php/*/fpm/pool.d/*.conf
- Найдите причину долгого обслуживанияЕсли 0 свободных процессов и растёт max children reached, проверьте slowlog, соединения к базе и внешним службам. Если обработчики есть, но соединения отклоняются, осмотрите сокет, сетевые ограничения и журнал веб-сервера.
- SSH, права администратора, пример PHP 8.2Linux · Терминал (Bash)КомандаНужен sudoSSH, права администратора, пример PHP 8.2. Время сверяйте с часовым поясом сервера; журнал может содержать данные, которые не следует публиковать.
sudo journalctl -u php8.2-fpm --since "30 minutes ago" --no-pager | tail -n 100
- Проверьте границы очереди без изменения параметровДля TCP-прослушивания смотрите ss -ltnp, для Unix-сокета ss -lxnp. Убедитесь, что listen.backlog задан для нужного пула. На Linux фактическая длина очереди дополнительно ограничена net.core.somaxconn; увеличение одного параметра не отменяет другого.
- SSH, только чтение параметров ядра и Unix-слушателейLinux · Терминал (Bash)КомандаНужен sudoSSH, только чтение параметров ядра и Unix-слушателей. На некоторых системах пути и отображаемые имена отличаются.
sysctl net.core.somaxconn; sudo ss -lxnp | grep -E "php|fpm"
- Меняйте параметры только по наблюдениямЕсли узкое место — медленные запросы, прежде устраните их. Если подтверждена достаточная свободная память и рабочие процессы ограничены, осторожно пересчитайте pm.max_children с учётом пикового RSS и всех остальных служб. Если основная причина — переполнение очереди соединений, после испытаний можно точечно повысить listen.backlog и системный предел, подготовив откат.
- Перечитайте конфигурацию и проведите измерения повторноСделайте копию pool.d, выполните тест версии FPM и аккуратный reload нужного экземпляра. В часы похожей нагрузки сравните listen queue, p95 задержки, max children reached и память с исходными значениями; при ухудшении верните старые значения.
#Как проверить, что проблема исправлена
Очередь быстро разгружается, HTTP 502/504 исчезли, занятость памяти остаётся в пределах безопасного резерва.
#Если не помогло — дальнейшая диагностика и откат
Если очередь растёт при свободных обработчиках, ищите сетевые ограничения, неверный адрес listen, лимит соединений прокси и ошибки сокета. Не отключайте защиту от запросов для эксперимента.