Requests are never queued after pm.max_children with Nginx and PHP-FPM

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

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:

The number of child processes ... to be created when pm is set to dynamic.

This option sets the limit on the number of simultaneous requests that will be served.

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 for listen.backlog. This defines the queue length (reference):

The backlog argument defines the maximum length to which the queue of pending connections

However, this value is limited by the underlying system. See:

sysctl net.core.somaxconn

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 the php-fpm process for so long.