CODEWITHSUNDEEP
php
kaychaks
kaychaks

Reputation: 1775

Can we reload one of the PHP-FPM pool without disturbing others

I've multiple PHP-FPM UNIX socket pools for the same host to have logical separation of codebase / functionality & to address future scaling of the same. Nginx manages the routing to the right socket based on URI patterns. Deployment is working fine.

Whenever I change pool configuration for any one, I am reloading / restarting the FPM process (by USR2 signal).

I don't have any idea about how the internals of FPM work but I assume that as I restart the main process, all pools get restarted / reloaded. Please correct me if I'm wrong.

I want to know if I could reload / restart only one pool when others work as they were (no issues in the undergoing transactions on those pools).

I would also appreciate any other configuration suggestions which could allow me to have desired pool management

Upvotes: 48

Views: 53389

Answers (2)

Ray
Ray

Reputation: 373

Although there is already a best answer, I'm writing to provide more information missed from the best one.

  • After reload is executed, PHP-FPM will wait until all requests are processed but not longer than process_control_timeout. If it reaches process_control_timeout, a 502 error will occur
  • While waiting for all requests processed, PHP-FPM WILL NOT process any new requests, instead, it queues them. Because a new reloaded process will only be created after all old requests are processed.

which leads to some facts and issues:

  • When speaking zero downtime, does delayed processing count?
  • How many requests the server would be able to queue?
  • Of course, delayed processing means the page would get stuck on the user side.

Upvotes: 11

regilero
regilero

Reputation: 30526

php-fpm allows for a graceful restart of childs, usually with the reload keyword instead of restart on the init script, sending USR2 signal.

So by doing a graceful restart you should not loose any running transaction. The children are killed after the end of the current request management for each of them. This should be enough if you do not need a real restart. I made some tests and for example a reload is enough to :

  • empty the APC cache
  • alter log file path
  • alter min/max/start child settings

So I did not find a case where a need a real restart yet. Except that a reload cannot start a stopped service.

If you want to ensure other pools will never be reloaded when you want to reload one of them you will have to manage several php-fpm daemons and one pool per daemon. This implies writing several init scripts and master configuration files.

Using the restart keyword is more dangerous, especially because the init script is maybe killing long running children in the stop step. And with several daemons managed with several PID and configuration files you could even get a start-stop-daemon command with --exec option (that's the case in debian) and this would kill all the daemons running the same php-fpm executable (effectively sending a kill -9 to all the other parallel php-fpm daemons after stopping the right one with the right PID if you run several php-fpm processes, which is very bad).

So using the reload keyword (USR2 signal) is a must.

Upvotes: 61

Related Questions