CPU负载排查
2013-2-27 早10点左右收到短信报警，服务器CPU负载超过15
打开监控平台，CPU利用率100%，负载高达123
打开前台 页面发现速度缓慢。肯定是出问题了
通过ssh 远程到服务器使用TOP命令
发现负载的确很高,基本上都是Php-cgi占用的
根据以往经验,一般重启Php问题可以解决，
重启以后的确 负载下来了，可是过了大概半个小时，又收到报警负载高
这次重视了，查看到进程数有300个，不对劲，正常服务器进程在255-256左右，怎么多了40个进程
我开启的Php-cgi有128个
Ps –aux |grep php |wc 发现有150多个 仔细查看分析原来有一个计划任务在跑\
*/1 * * * * /usr/bin/curl
利用curl定期没分钟去访问这条URL 没有设置数据传输和超时时间,前几天这台服务器有断网20分钟 于是这几天URL一直存在
询问了研发人员 更改策略
* */1 * * * /usr/bin/curl --connect-timeout 5 -m 10 一个小时执行一次,同时测试超时时间5秒数据传输超时时间10秒
将这些任务产生的进程kill掉，不过应该不是CPU负载超高的原因
到底是什么原因引起的
静下心来,从头开始分析.CPU负载高-----检查内存正常—检查磁盘IO负载正常---检查进程---(发现running的进程在慢慢增多)
当时R—有80多,正常有3-5都偏高的了
[root@www forum]# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 12328 1049520 407224 13841064 0 0 94 210 52 74 6 6 88 0
IO 查看%util 也很低
将Php-cgi占用CPU最高的前几条排序
ps H -e -o pid,tid,pcpu,cmd --sort=pcpu |grep php-cgi
lsof –p PID
发现都是引用/data0/data_www/XXXXX这个文件夹的网页
同时查看数据库状态..的确数据库运行今天也是偏慢.可是状态基本正常.偏慢应该是CPU负载过高引起.任务队列过长导致
查看nginx 前端负载并发只有300多, 可见没有收到DDOS***,而且访问量不大
询问开发人员，告知今天没有代码改动，可是根据分析，的确就是yunpos.com这个文件
Strace –p PID 进程在不停写
Ll /preo/PID/fd 一些socket 和PIPE 看起来还是很正常的
唉.没办法那日志分析一下,
分析一下一下nginx的访问日志,看下有没有异常,截取一小段最近日志.
拿出来分析cat XXX.log |grep "27/Feb/2013" |goacces
排第一个的是/testspeed.htm测试客户端和服务端连通性.
第二个/testsyncdata.php确定联通之后的数据同步
看上去也没有什么问题.都是很早之前就有的
在打开php错误日志,发现只有一些普通的通知和警告错误
到这里卡住了. 查看配置文件php-cgi设置超时时间是30秒
打开php-slow慢日志 tail –f slow.log
盯着屏幕
发现都是类似这种的PID 慢日志.奇怪 这个php是做什么的
我试着访问了一下, 无法访问..奇怪
问了下开发人员,这个是下载安装包的php 速度慢是正常的
可是觉得很不对啊,下载慢, 日志刷新挺快的啊,.不停的有这么多人在下载?
而且我访问无法打开.
于是让研发人员看一下代码为什么没有弹窗下载
终于找到问题了…
原来今天一个研发人员上传了一个新的安装包,安装包名称是XXXXl零售版2.7.0.exe
而网页上调用的是XXXX.2.7.0.EXE 他当时只改了版本号,没有加零售版三个字..
在调用p_w_upload.php的时候 php去请求这个EXE文件可是没有找到30秒超时,不停有新的请求没有释放,导致running的进程过多,CPU队列太长,CPU负载升高,所以即使我重启了Php过2个小时左右CPU负载增长到120左右.在重启 正常,过了一会儿有出现问题的根本原因.
可是服务端php超时30秒相对比较合理太短了怕影响部分功能,感觉程序员应该在代码上加上某些php超时机制 才是合理的.
去吃了下饭 回来看负载正常,.可以安心下班了.
遇到负载异常大体思路：查看流量情况，TCP连接数，top,ps，查看占用进程，然后IO, 程序改动，最后分析各种日志，代码了