PHP-FPM: переполняется listen.backlog при высокой нагрузке

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

Во время нагрузки PHP-FPM перестаёт быстро принимать новые соединения, в статусе растёт listen queue и фиксируется переполнение очереди входящих подключений. Разбираем связь listen.backlog, pm.max_children и ограничения ядра Linux. Очередь backlog — место для подключений, ожидающих принятия сервером, а не средство ускорения самих PHP-скриптов. Повышение listen.backlog может снизить краткие отказы, но увеличивает время ожидания и не устраняет перегруженные обработчики.

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

1. Подтвердите признаки очереди, не меняя параметры по одному 502В момент ошибки запишите время, количество обращений и код ответа Nginx. Ищите в error_log connect() failed, upstream timed out или no live upstreams и уточните фактическую причину. Ответ 502 не доказывает переполнение backlog: он бывает при удалённом сокете, аварийном PHP и неверных разрешениях. Наблюдение проводите на рабочей нагрузке без искусственного усиления атаки или теста на отказ.

1. Определите точный слушающий сокет PHP-FPMВ конфигурации виртуального сайта откройте fastcgi_pass, а в действующем пуле — listen. Пути или адреса IP:порт должны совпадать. Если Nginx использует TCP, проверяйте TCP-очередь; если Unix-сокет — Unix-очередь. Не пытайтесь устанавливать listen.backlog в конфигурации Nginx: этот параметр относится к стороне PHP-FPM.

1. Посмотрите статус пула, если он уже защищённо настроенЧерез закрытый адрес pm.status_path выясните listen queue, max listen queue, listen queue len, active processes, idle processes и max children reached. Запишите значения до и во время пика; listen queue — текущая очередь, max listen queue — накопленный максимум. Если страницы статуса нет, сначала настройте её доступ только администратору, не открывайте всем. Насыщенная очередь при занятых работниках означает нехватку свободной обработки, а не обязательно маленький backlog.

1. Проверьте очерёдность соединений и предел ядра LinuxПо SSH из терминала Windows/Linux выполните ss -ltn для TCP либо ss -xln для Unix-сокетов, затем sysctl net.core.somaxconn. Для слушающих сокетов Recv-Q и Send-Q помогают оценить текущую очередь и предел, хотя формат зависит от типа. somaxconn — верхняя граница для backlog на Linux. Команды только читают данные; если ss не найден, попросите администратора выполнить штатное средство диагностики.
2. Команды Linux для просмотра очередей и системного предела

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Команды Linux для просмотра очередей и системного предела. Без sudo; не изменяют параметры ядра.

   ss -ltn

   ss -xln

   sysctl net.core.somaxconn

1. Разберите, почему работники не принимают новые запросыЕсли active processes уже равно pm.max_children и растёт время ответа, найдите длительные операции в slowlog, журнале приложения или SQL. Проверьте внешние API и обработку архивов. Устранение длительного запроса эффективнее увеличения глубины очереди, в которой остальные посетители будут ждать те же занятые процессы. Поднимать pm.max_children без проверки RAM нельзя.

1. Сохраните конфигурацию и измените backlog только при измеренной необходимостиЕсли пиковая очередь действительно упирается в установленный размер, обработчики остаются работоспособными и есть кратковременный спрос, согласуйте увеличение listen.backlog до проверенного значения, например 256 или 512. Эти числа — примеры, не универсальные рекомендации. Убедитесь, что системный net.core.somaxconn не ниже выбранного значения; изменение системного лимита требует отдельной оценки со стороны администратора и не обязательно нужно. Запишите старое значение пула и сохраните его файл.
2. Пример кода по теме

   INIКопировать всёВыделить

   Иллюстративный параметр активного пула; подбирайте после измерения и с учётом sysctl net.core.somaxconn.

   listen.backlog = 256

1. Протестируйте конфигурацию и примените её в окно обслуживанияДля Debian PHP 8.2 выполните sudo php-fpm8.2 -t. Если ошибок нет, согласуйте sudo systemctl reload php8.2-fpm. Для изменения слушающего сокета или некоторых пакетных сборок может потребоваться управляемый restart; это прервёт текущие запросы, и его нельзя делать в самый пик. Убедитесь, что после применения сокет существует, а ss показывает ожидаемый предел. При несовпадении отмените правку и проверьте, тот ли файл пула меняли.

   Linux · Терминал (Bash)С осторожностьюНужен sudoКопировать всёВыделить

   Debian PHP 8.2: после успешного теста, права администратора. Перезапуск вместо reload только по подтверждённой необходимости и в согласованное окно. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.

   sudo php-fpm8.2 -t && sudo systemctl reload php8.2-fpm

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

1. Сравните задержки и число отказов при сопоставимом трафикеВ следующий сопоставимый период посмотрите максимум очереди, фактическое время ответа и 502/504. Если новые соединения принимаются, но долго ждут, значит backlog лишь сгладил отказ и нужен анализ длительности PHP-запросов. Если очередь стала больше, а время ответа ухудшилось, верните прежнее listen.backlog, пройдите тест конфигурации и reload. Не включайте небезопасный тест высокой нагрузкой на боевом сайте.

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

Успех — при сопоставимом пике снизилось число ошибок соединения, очередь не остаётся заполненной постоянно, время ответа приемлемо, процессы и RAM не исчерпываются. Если значения не меняются, проверьте sysctl, действующий пул, лимит процессов и источник длительных запросов; при ухудшении откатите изменения через резервную копию.