Как только пул достигает pm.max_children, Nginx начинает тайм-аут при попытке отправить новые запросы в PHP-FPM. "max listen queue" всегда равен 0 на странице php-status.
Вот пример пула php-fpm:
[example]
catch_workers_output = no
; Configure listener
listen = /var/run/php-fpm/example.sock
listen.backlog = 65535
listen.owner = nginx
listen.group = nginx
; Unix user/group of processes
user = nginx
group = nginx
; Choose how the process manager will control the number of child processes.
pm = ondemand
pm.max_children = 10
pm.max_requests = 200
pm.process_idle_timeout = 30s
pm.status_path = /status
; Pass environment variables
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
; Host specific php ini settings here
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /tmp:/var/www/apc:/var/www/wordpress/example
php_admin_value[error_log] = /var/log/php-fpm/example.log
Поскольку этот вопрос все еще появляется среди вопросов, на которые нет ответов, я попробую дать устаревший ответ. Отображение ошибки - это предполагаемое поведение параметра pm.max_children в соответствии с Руководство по PHP:
Количество дочерних процессов ... которые будут созданы, когда pm настроен на динамический.
Эта опция устанавливает ограничение на количество одновременных запросов, которые будут обслуживаться.
Однако каждый запрос должен обрабатываться довольно быстро, чтобы процесс освободился для следующего запроса. Если не, nginx вероятно, сообщит «502 Bad Gateway», как только не сможет обработать больше запросов.
Еще раз проверьте значение, установленное в php-fpm конфигурация для listen.backlog. Это определяет длину очереди (ссылка):
Аргумент backlog определяет максимальную длину очереди ожидающих подключений.
Однако это значение ограничено базовой системой. Видеть:
sysctl net.core.somaxconn
Насколько я знаю, нет возможности поставить в очередь запрос к восходящему (php-fpm), если это вызывает ошибку. Тем не менее, вы можете указать nginx переключиться на другой процесс в случае возникновения ошибки. Это может вызвать, например, перезагрузку на стороне клиента.
Если это не listen-backlog/net.core.somaxconn , то фактический вопрос, однако, заключается в том, почему запросы блокируют php-fpm процесс так долго.