线上不出点问题, 似乎今天就不是周五了.
突然报警群里出现了某一条数据, 反馈没有上报成功, 中间流程执行完, 后面没再执行了(细思极恐)
无语。。。
想了想刚才有发版, 但是不是这个引起的还不确定 (我们目前没有灰度发布-_-)
1. 从日志中丰富问题信息
首先我得确定下这条数据的到达时间, error日志查, 查看业务日志是否有过重要的打点信息, 通过从access日志里面, 定位到这条问题数据请求时间为 10:22:42
2. 10:22 我们做了什么?
通过查看聊天记录,10点多有个上线操作, 并且别的项目之前一上线就抱怨说可能就会有502出现, 由此我想我们发布服务中间可能操作了什么出现的问题
嗯。。万事不求人, 看下php-fpm的日志就知道啥时候上过线了(我们构建项目会重启fpm).
发现php-fpm.log文件内容:
[19-Apr-2019 10:22:42] NOTICE: Reloading in progress ...
[19-Apr-2019 10:22:42] NOTICE: reloading: execvp("/usr/local/php-fpm_9000/sbin/php-fpm", {"/usr/local/php-fp
m_9000/sbin/php-fpm", "--daemonize", "--fpm-config", "/usr/local/php-fpm_9000/etc/php-fpm.conf", "--pid", "/
usr/local/php-fpm_9000/var/run/php-fpm.pid"})
[19-Apr-2019 10:22:42] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[19-Apr-2019 10:22:42] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[19-Apr-2019 10:22:42] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[19-Apr-2019 10:22:42] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[19-Apr-2019 10:22:42] NOTICE: using inherited socket fd=8, "127.0.0.1:9000"
[19-Apr-2019 10:22:42] NOTICE: using inherited socket fd=8, "127.0.0.1:9000"
[19-Apr-2019 10:22:42] NOTICE: fpm is running, pid 23324
[19-Apr-2019 10:22:42] NOTICE: ready to handle connections
nginx错误:
[error] 66#0: *10 recv() failed (104: Connection reset by peer) while reading response header from upstream
这个错误很熟悉吧,之前文章已经介绍过了.
3. 先下个结论,顺着这个想想
发布服务重启php-fpm, 导致的代码流程执行中断.
4. 等等, 应该是平滑重启,怎么会中断?
首先思考中断可能的原因:
- 代码某个点执行时间过长,timeout
- 资源不够,比如内存溢出中断
- 代码bug、异常
- 服务器断电
- ....
这些问题应该不会, 这个被中断的服务 没有依赖的服务请求, 也没有复杂的业务逻辑.(不要问为啥没问题,因为这是我写的+_+)
5. 平滑重启为什么不平滑?
借助着搜索引擎的力量, 找问题就变得傻瓜起来
-
记 php-fpm 重启导致的 程序执行中断问题 yq.aliyun.com/articles/22…
-
重启php-fpm时请求发生502错误的原因及解决:process_control_timeout www.04007.cn/article/439…
-
PHP-FPM参数 www.jianshu.com/p/795a1a181…
-
Graceful Restart (USR2) isn't very graceful bugs.php.net/bug.php?id=…
最后详细的读了下最后一篇向官方反馈的bug, php-fpm的平滑重启不平滑
其中目前建议:
[2013-02-13 15:57 UTC] phpbugs at oops dot mooo dot com
Try setting process_control_timeout to something higher than 0.
process_control_timeout 参数解释
参数含义是 设置子进程接受主进程复用信号的超时时间. 控制子进程处理来自master的信号的时间,默认为0.如果正在处理请求, 很可能会收到错误报警。建议将此参数设置为相同的值 request_terminate_timeout,以便worker有时间完成处理请求。
验证
echo 1;sleep(10);echo 3;
访问中, 进行 kill -USR2 10 报错:
将 php-fpm.conf 的 process_control_timeout 配置为20
进行 kill -USR2 11
正常输出结果.
结论
后续是否有副作用还需要在生产环境验证
服务发布优化也不仅于此
为什么要每次重启fpm
比如能不能用其他方式使缓存失效呢?