记一次php5-fpm事故处理

公司维护的游戏，经过我的一次合服以及平台迁移后， 平台总是挂掉，报 502错误

通过https://zhidao.baidu.com/question/363653026340196772.html 这篇文章了解了一点，知道  nginx并没有真正挂掉，

只是PHP-CGI 进程终止。

当时为了应急（平台一挂掉所有玩家都不能登录的），重启了 nginx 服务以及 php5-fpm服务。

后续才开始慢慢查询问题：

1. 查询nginx 日志

2018/09/16 15:42:47 [error] 26489#0: *244324 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: x.x.x.x, server: xxx, request: "GET /muhstik-dpr.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "x.x.x.x"

网上搜寻相关的报错，，都是涉及php 优化的问题， 经过对比 另外一个平台  的nginx 错误日志，发现 他的nginx 错误日志也有这种报错，所以排除 nginx 出错的可能。

2. 优化php5-fpm

中间 有down掉过几次，一直都是 临时方案，，直接重启 php5-fpm

网上说的多半是 php5-fpm 进程把内存占满了，需要优化一下配置文件

公司服务器 是8core 16G 的配置

修改www.conf 文件以下字段：

pm = static    （php进程设为静态，默认为动态）

pm.max_children = 100  （php进程数设为100）

加上php主进程刚好101个

再后来，平台再也没有down过。

3. CPU监控

通过  ucloud后台监控服务器，发现这段时间 的 服务器CPU异常爆炸，疯狂满额。

到服务器上 top 观看，发现每过一段时间像

www-data 26196 26101 0 Sep17 ? 00:00:00 php-fpm: pool www  这种进程，大约出现四五个，会把CPU 全部吃掉

问题到这里就非常明朗了： 

一开始 php5-fpm 没有经过优化，默认是动态产生上面的进程，最大个数是五个，五个进程慢慢的吃掉整个CPU，

而且其实当这几个进程占100%CPU的时候，就相当于php5-fpm进程已经进入假死状态了，根本就不工作了，这就是之前为什么

登录后台会报 502 的原因。 当进行 优化后， php5-fpm进程开到了100个，即使那五个进程倒下了，还有95 个pool www  进程在继续工作

虽然 CPU被占满了，但是会还是能工作的，还好这进程吃掉的是CPU，如果是  内存，估计服务器直接就挂掉了 。

4. 追溯问题本源

出现 CPU 和 Memory 被占满这种问题， 多半是 数据库慢语句的 问题 或者就是 后端代码本身的问题 。

但是进 云数据库查看了那个阶段的  慢日志， 并没有发现 大量的慢查询 语句。

问题就显而易见了，估计是后端代码有bug。

然后就是给php5-fpm 添加慢日志（执行php脚本超过5秒 就会被记录），配置文件  www.conf 添加如下字段：

access.log = var/log/access_php5-fpm.log

slowlog = log/slow.php5-fpm.log

request_slowlog_timeout = 5

监控 slowlog 日志：

发现问题的根源就是这个：

肯定就是马赛克部分  路径源代码出了问题，上报给开发人员，下面就是开发人员的事情了。

后续： 确实是代码出了问题，等他们优化修改了以后，最后重启一次 php5-fpm服务，就再也没有出现问题。

总结： 遇事莫慌，问题得慢慢查，多找资料，多开日志记录，各个服务能优化的就尽量优化 . （能做到不慌也挺不容易的，当时整个合服和平台迁移工作都是我一个人做的，还是很慌得，立即就上报了老大，老大说以前也出现过这种问题，所有我才稳了一波继续完成下面的排查工作）