Nginx – PHP-FPM + NGINX: PHP-CGI processes die after a while in idle, then 502 bad gateway and manual restart required

fastcginginxPHPphp-fpm

I am currently setting up a VPS (with VPS.NET) which I will be using to host a blog and some other stuff. I've installed nginx, and patched php (5.2.8) with php-fpm.

All works great (and extremely fast!), apart from one annoying issue: because the website has no other traffic than mine for now, after a while it has been in idle all the php-cgi processes die. As soon as I then try to visit the website, nginx returns a nice "502 bad gateway", and to fix I have to manually restart php-fpm to get the website to work again.
Why is that?
I have seen this is somehow a common problem but after a few days looking for a solution in my spare time, I have found none that works for me.

Any suggestions?
Thanks in advance

Best Answer

I am running a very similar set up (nginx 0.7.61, php+fpm 5.2.10) and my PHP processes never die, even after being idle.

The process control bits of my php-fpm.conf are as follows:

<value name="pm">
    <value name="style">static</value>
    <value name="max_children">3</value>
    <value name="apache_like">
        <value name="StartServers">20</value>
        <value name="MinSpareServers">5</value>
        <value name="MaxSpareServers">35</value>
    </value>
</value>
<value name="request_terminate_timeout">0s</value>
<value name="request_slowlog_timeout">0s</value>
<value name="slowlog">logs/slow.log</value>
<value name="rlimit_files">1024</value>
<value name="rlimit_core">0</value>
<value name="chroot"></value>
<value name="chdir"></value>
<value name="catch_workers_output">yes</value>
<value name="max_requests">500</value>

Note that while I have the apache-like bits defined (they were part of the default config), they aren't used because I have PM style static set.

You can turn up the logs to debug level using this in the global options section:

<value name="log_level">debug</value>

to see if there's a reported reason that it's shutting down workers.

A latch-ditch fix if this doesn't work would be to have a service like pingdom hit a php on your site every x minutes, but my experience with this software combo doesn't suggest that this should be required.