2

起步

在测试中,发现 php-fpm reload 会强制 kill 掉正在处理的请求。网上查了一下,发现其他人也有这个问题并反馈给了官方:https://bugs.php.net/bug.php?id=75440https://bugs.php.net/bug.php?id=60961,帖子是 2017 和 2012 年的,到现在还没解决。

官方帮助手册还说 reload 是 graceful ,啊哈哈,不要太相信:

man php-fpm
...
SIGINT,SIGTERM
    immediate termination
    SIGQUIT 
graceful stop
    SIGUSR1 
re-open log file
SIGUSR2
    graceful reload of all workers + reload of fpm conf/binary
...

reload 流程简介

php-fpmmaster worker 的工作方式。

php-fpm master 进程通过接受用户发送的 SIGUSR2 信号实现自身服务的 reload:

kill -USR2 <pid>

主进程(master进程)收到 reload 信号,会向所有子进程发送 SIGGUIT 信号,同时注册定时器时间,timeout 的值为 fpm_global_config.process_control_timeout 。在规定时间之内子进程还没有结束,则子进程将被 kill 。比如 timeout 值设为1秒,如果在 1 秒之内还没有结束,则直接向子进程发送 SIGKILL 信号,强制杀死。

最后 master 等待所有的子进程结束后,根据之前保存的启动参数重新启动一个进程,并继承父进程的 socket 文件描述符。

缓兵之计

注意,这只是缓解的方案,依然不能保证请求不会丢失。这个方案在于 process_control_timeout 这个配置选项,配置文件在 php-fpm.conf (我的是在 /usr/local/etc/php-fpm.conf)中,默认值是 0 ,会立即将子进程 kill 掉,这里我改为了 60s 进行测试:

; Time limit for child processes to wait for a reaction on signals from master.
; Available units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
process_control_timeout = 60s

测试结果,正在处理的请求只要在该时间内完成请求,就能正常返回。

这不是 100% 的方案是因为,master 进程要等待所有子进程结束才会重新创建 worker 进程,而 process_control_timeout 等待的时候,worker 进程不接受请求了,因此这段时间内新的请求进不来,这些新请求将由 fpm 排队,nginx 若超时会报 502 给用户,保险起见,nginx 的超时时间的值应该是 process_control_timeout 的两倍。

尽管可能会报 502 ,但这样的处理方式比杀死正在处理的请求让人接受的多了。

总结

尽管设置了 process_control_timeout ,在上述情况之上,PHP-FPM 在 reload 完成之前不会为新请求提供服务。但是,所有这些新请求将由 fpm 排队,并在重新加载完成后立即执行。最终用户的结果是,在此期间,他们看到浏览器显示加载中。另一点是设置的超时,也不能保证请求在这个时间内处理完,还是需要程序员保证自己的脚本运行时间在合理范围内。


weapon
3.2k 声望232 粉丝

宝可梦情怀粉;刀塔手残党;浴室麦霸王。