As soon as a pool reached pm.max_children, Nginx starts timing out when trying to send new requests to PHP-FPM. "max listen queue" is always 0 in the php-status page.
- PHP-FPM 5.5.16
- Nginx 1.6.1
Here is the example for a php-fpm pool:
[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
Best Answer
As this question still shows up in the unanswered questions, I'll try with a outdated answer. Showing an error is the intended behavior of the setting "pm.max_children", according to the PHP manual:
However, each request should be handled quite quickly, so the process becomes free for the next request. If not,
nginx
will probably report a "502 Bad Gateway" as soon as it cannot handle more requests.Double-check the value set in the
php-fpm
configuration forlisten.backlog
. This defines the queue length (reference):However, this value is limited by the underlying system. See:
As far as I know, there's no way to queue a request to the upstream (
php-fpm
), if this throws an error. Yet, you may tell nginx to switch to another process, if the error occurs. This may trigger a client-side reload, for example.If it's not the
listen-backlog
/net.core.somaxconn
setting, then the actual question, however, is why requests block thephp-fpm
process for so long.