Listening to the Words

一次cpu使用率100%的惊魂之旅

《一次cpu使用率100%的惊魂之旅》

最近突然有一天,运维同事找到我说你的项目出现了问题,我心中一惊,赶紧一起追问是什么异常,他打开项目监控说你的php程序很奇怪,内存使用正常,php-fpm进程使用正常,系统其它资源都正常,但是只有CPU一下子飙到了100%,我大吃一惊,这….

按照这个情况来说,cpu占用超高一定是系统I/O导致的,我仔细思索我的程序哪里出现了问题是网络I/O导致的进程挂起吗?还是队列里出现了睡眠函数等能阻塞进程的因素?

就这样一直找,一直排除各种因素,但是好几天都没有任何结果,更危险的事情来了,系统负载到了16以上,用户已经明显感受到卡顿了,紧要关头运维建议加一台机器做负载无奈同意了,运维同事部署新机器同时清理了下现在项目的日志,然后事情在这点出现了翻转。

CPU使用率在一分钟后突然回到了个位数,运维大惊赶紧问题是刚才做过什么操作吗?我说没有啊,我赶紧查看日志,确实系统正常了,然后我们共同认为是日志导致的,这下定位了问题的原因。

没错,问题就在日志,想起前几天我修改了thinkphp日志的选项,其中有个max_fizes 参数,这个参数一旦设置为大于0,系统就会自动维护当前日志的数量,超过这个数量就会自动清理,乍一看这个功能很不错,但这次的事故确正式由于这个各功能导致的,我设置的参数为5000,这就要命了,以为这每次写入日志程序都会通过glob() count() unlink() 三个函数判断当前日志的维护状态,这是多么消耗资源的I/O啊,也难怪系统CPU一直飙升了.

最后解决的办法是设置max_files=0,不在开启这个参数.真是一个销魂的设置啊,项目组看的是魂飞魄散的!

以下是我的排除思路:

  • 查看系统php-fpm慢日志
  • stace 查看php-fpm 进程调用
  • 思索最近增加的业务会不会导致网络I/O超时
  • 使用APM(听云)监控系统分析php调用栈(docker 环境下未能成功)
点赞