What does “graceful reload” actually mean with php fpm

php-fpm

The php-fpm man page states the response to a USR2 signal is: "graceful reload of all workers + reload of fpm conf/binary". However, in testing I find that a reload actually kills workers processing requests. I was expecting requests to be allowed to finish before the processes were killed and re-spawned.

Is this broken, my expectation wrong, or test invalid?

My test setup:
Ubuntu 16.04 LXC container
install php7.0-fpm and nginx
php script to sleep and output countdown each second
send request to sleep for 30 seconds via curl
issue reload via systemctl

Test result:
request was killed immedietly upon reload

Best Answer

I just found my answer: configuration option process_control_timeout was set to a default value of 0 seconds. A terrible default in my opinion.

I set process_control_timeout to a value of 30s to allow child processes up to 30 seconds to complete and quit before being forcibly killed. However, this takes effect only on subsequent reloads as the first reload is required to put this change into effect.

Related Solutions

Nginx – How to restart php-fpm

Note: prepend sudo if not root

Using SysV Init scripts directly:

/etc/init.d/php-fpm restart    # typical
/etc/init.d/php5-fpm restart   # debian-style
/etc/init.d/php7.0-fpm restart # debian-style PHP 7

Using service wrapper script

service php-fpm restart    # typical
service php5-fpm restart   # debian-style
service php7.0-fpm restart # debian-style PHP 7

Using Upstart (e.g. ubuntu):

restart php7.0-fpm         # typical (ubuntu is debian-based) PHP 7
restart php5-fpm           # typical (ubuntu is debian-based)
restart php-fpm            # uncommon

Using systemd (newer servers):

systemctl restart php-fpm.service    # typical
systemctl restart php5-fpm.service   # uncommon
systemctl restart php7.0-fpm.service # uncommon PHP 7

Or whatever the equivalent is on your system.

Nginx – Constantly have to reload PHP-FPM

You're using php-fpm, so I suggest to be more aggressive with how long php-fpm's children are allowed to live. You need to find the sweet spot between shortly lived threads/children and stability. The php-fpm defaults are way to generous for any production system, IMHO.

I'd reduce the number for pm.max_requests for your production pools. I think the default is 200. I'd start from 50 and see where that takes you.

Failing/complementary to that, you could also try these global options (AFAIK they are all disabled by default):

emergency_restart_threshold=3
emergency_restart_interval=1m
process_control_timeout=5s

What does this mean? If 3 PHP-FPM child processes exit with SIGSEGV or SIGBUS (i.e. crash) within 1 minute then PHP-FPM is supposed to restart automatically. The child processes wait 5s for a reaction on signals from master.

This should keep your pool of PHP worker threads nice, fresh and clean. The longer a worker is allowed to furnish requests, more unstable it will get. There's also a higher risk of memory leaks.

Here's a nice overview of all the config options I mentioned here, as well as others: http://myjeeva.com/php-fpm-configuration-101.html

Hope these tips help you! Remember to tweak and observe, unfortunately there doesn't seem to be a rule of thumb for all this, there are too many variables that affect PHP's behaviour and stability.

Best Answer

Related Solutions

Nginx – How to restart php-fpm

Nginx – Constantly have to reload PHP-FPM

Related Topic