起步
在测试中,发现 php-fpm reload 会强制 kill 掉正在处理的请求。网上查了一下,发现其他人也有这个问题并反馈给了官方:https://bugs.php.net/bug.php?id=75440 和 https://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-fpm
是 master worker
的工作方式。php-fpm master 进程通过接受用户发送的
SIGUSR2
信号实现自身服务的 reload
:kill -USR2
主进程(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 ,但这样的处理方式比杀死正在处理的请求让人接受的多了。
总结 【关于 php-fpm reload 会取消正在处理的请求的解决方案】尽管设置了
process_control_timeout
,在上述情况之上,PHP-FPM 在 reload 完成之前不会为新请求提供服务。但是,所有这些新请求将由 fpm 排队,并在重新加载完成后立即执行。最终用户的结果是,在此期间,他们看到浏览器显示加载中。另一点是设置的超时,也不能保证请求在这个时间内处理完,还是需要程序员保证自己的脚本运行时间在合理范围内。推荐阅读
- include文件包含伪协议
- 22.4.3 php语言文件包含基础
- 22.4.2 php语言循环结构 2
- 22.3.27学习日记(php语法基础)
- php实现抖音开放平台账号授权获取码code、获取access_token
- 抖音|抖音开放平台开发记录
- 服务器|Arm、Intel 和 AMD 服务器 CPU未来2年市场发展分析
- webpack|采用 vue+webpack 构建的单页应用——私人博客 MintloG 诞生记
- Python|Python和PHP有什么区别