线上不出点问题, 似乎今天就不是周五了.

突然报警群里出现了某一条数据, 反馈没有上报成功, 中间流程执行完, 后面没再执行了(细思极恐)

无语。。。

想了想刚才有发版, 但是不是这个引起的还不确定 (我们目前没有灰度发布-_-)

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. 平滑重启为什么不平滑?

借助着搜索引擎的力量, 找问题就变得傻瓜起来

最后详细的读了下最后一篇向官方反馈的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有时间完成处理请求。

验证

<?php
  echo 1;
  sleep(10);
  echo 3;

访问中, 进行 kill -USR2 10 报错:

将 php-fpm.conf 的 process_control_timeout 配置为20

进行 kill -USR2 11

正常输出结果.

结论

后续是否有副作用还需要在生产环境验证

服务发布优化也不仅于此

为什么要每次重启fpm

比如能不能用其他方式使缓存失效呢？

结束

更多有趣的计算机技术关注呆呆熊一点通 :