Nginx PHP-FPM stops after connection timeout

Question

I have a server with Nginx and PHP-FPM for a single web application. Everything works will until I make a request for a page that takes over the 60 seconds allowed. Then PHP stops responding to any request.

The steps to produce the issue are:

1: I make a request that take php/mysql longer than 60 seconds to return. At this point everything is still functional. All additional traffic still works just fine.

2: Then I make another request in the UI (change pages).

3: Now all PHP traffic just stops - PHP no longer delivers content so all requests wait until the timeout is reached and Nginx returns 'An error occurred'. The logs show ... upstream timed out (110: Connection timed out) while reading response header from upstream ....

The web application is AngularJS making AJAX request to PHP. I'm testing the UI in Chrome and requesting test pages with Safari so it's not Chrome just being stupid and waiting for a request.

Restarting php-fpm fixes the problem. I've tried setting the emergency reset and it has no effect. The log file /var/log/php5-fpm.log is empty.

php-fpm.conf

[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
include=/etc/php5/fpm/pool.d/*.conf

www.conf

[www]
user = www-data
group = www-data
listen = /var/run/php5-fpm.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
chdir = /
catch_workers_output = yes

nginx site config

...    
location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}
...

Answer 1

The problem is pm.max_children too low (perhaps 200 is better). It was also recommended to me to change pm to ondemand instead of dynamic. And to set pm.process_idle_timeout to 1s so it will cycle them out.

The problem is the ajax requests were taking up the 5 available workers so then subsequent requests can't go anywhere.