善于sar工具来分析系统问题
2012-07-12 16:36:22   来源:我爱运维网   评论:0 点击:

sar的功能是非常强大的,很多系统的性能瓶颈都可以从sar的历史数据中分析出来。大家需要学会善用sar工具来分析排查系统问题。

现象:

最近收到一些cutter业务相关的有cpu high load(CPU高负载)报警:

Issue: CPU load is too high on CUTTER。

以其中一台cutter业务服务器为例(shl  215.212)

查看zabbix的监控图表,可见:
 
Load:
善于sar工具来分析系统问题
可以明显的看出,在15-17分钟左右就会出现一次高峰期
 
一个比较详细的图:
善于sar工具来分析系统问题
 

排查过程:

对sar的日志进行分析:
Load(sar进行负载分析:sar -f 文件名 -s 开始时间 -e 结束时间 -q):
sar -f sa12 -s 07:00:00 -e 07:40:00 –q  #可以看到两个高峰的load值
 
07:00:01 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
07:07:01 AM       all      1.99      0.04      1.56      1.43      0.00     94.99
07:08:01 AM       all      1.00      0.04      1.24      0.52      0.00     97.20
07:09:01 AM       all      0.72      0.02      1.16      0.50      0.00     97.60
07:10:01 AM       all      0.70      0.02      1.17      1.28      0.00     96.84
07:11:01 AM       all      1.08      0.02      1.44     14.75      0.00     82.71
07:12:01 AM       all      0.67      0.04      1.20      0.46      0.00     97.62
07:13:01 AM       all      0.68      0.02      1.15      0.54      0.00     97.62
07:14:01 AM       all      0.65      0.02      1.19      0.51      0.00     97.64
 
07:25:01 AM       all      0.67      0.02      1.16      0.62      0.00     97.53
07:26:01 AM       all      0.99      0.02      1.26      0.66      0.00     97.07
07:27:01 AM       all      1.22      0.02      1.41     11.36      0.00     86.00
07:28:01 AM       all      0.72      0.04      1.29      2.66      0.00     95.30
07:29:01 AM       all      0.67      0.01      1.19      0.66      0.00     97.45
 
 
Io(sar进行IO分析:sar -f 文件名 -s 开始时间 -e 结束时间 -u): :
 
sar -f sa12 -s 07:00:00 -e 07:40:00 –u  #load高峰时,io也比较高,这就说明load其实是由io引起
 
07:00:01 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
07:07:01 AM       all      1.99      0.04      1.56      1.43      0.00     94.99
07:08:01 AM       all      1.00      0.04      1.24      0.52      0.00     97.20
07:09:01 AM       all      0.72      0.02      1.16      0.50      0.00     97.60
07:10:01 AM       all      0.70      0.02      1.17      1.28      0.00     96.84
07:11:01 AM       all      1.08      0.02      1.44     14.75      0.00     82.71
07:12:01 AM       all      0.67      0.04      1.20      0.46      0.00     97.62
07:13:01 AM       all      0.68      0.02      1.15      0.54      0.00     97.62
07:14:01 AM       all      0.65      0.02      1.19      0.51      0.00     97.64
 
07:25:01 AM       all      0.67      0.02      1.16      0.62      0.00     97.53
07:26:01 AM       all      0.99      0.02      1.26      0.66      0.00     97.07
07:27:01 AM       all      1.22      0.02      1.41     11.36      0.00     86.00
07:28:01 AM       all      0.72      0.04      1.29      2.66      0.00     95.30
07:29:01 AM       all      0.67      0.01      1.19      0.66      0.00     97.45

同时可以看系统中断的情况:
中断(sar进行中断分析:sar -f 文件名 -s 开始时间 -e 结束时间 -P ALL
sar -f sa12 -s 07:00:00 -e 07:40:00  -P ALL   #cpu1上的IO中断比较多
 
07:08:01 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
7:11:01 AM       all      1.08      0.02      1.44     14.75      0.00     82.71
07:11:01 AM         0      0.70      0.03      0.15      3.41      0.00     95.70
07:11:01 AM         1      0.46      0.02      1.18     50.20      0.00     48.14
07:11:01 AM         2      0.20      0.01      0.45      0.27      0.00     99.07
07:11:01 AM         3      2.95      0.00      3.98      5.12      0.00     87.94
 
07:27:01 AM       all      1.22      0.02      1.41     11.36      0.00     86.00
07:27:01 AM         0      0.12      0.02      0.19      1.19      0.00     98.48
07:27:01 AM         1      0.57      0.04      1.08     34.72      0.00     63.58
07:27:01 AM         2      0.36      0.01      0.42      1.38      0.00     97.83
07:27:01 AM         3      3.81      0.03      3.92      8.13      0.00     84.10
 
而当前运行的php,nginx,cutter进程都不是运行在cpu1上的。
 
另外值得一提的是这个CPU高负载具有规律性,有可能是crontab和puppet导致的问题,通过对crontab和puppet的agent  log进行分析,发现也没有异常。
 
最后和研发确认,cutter应用自身的程序在每1000s左右会调用系统的rm 来删除旧的数据,这个就会导致io增高,原因就找到了。

结论(RootCause):

cutter应用程序本身的定期清理数据造成。需要研发优化此段代码。
  
可见,sar的功能是非常强大的,很多系统的性能瓶颈都可以从sar的历史数据中分析出来。大家需要学会善用sar工具来分析排查系统问题。
 

相关热词搜索:sar 分析 工具 CPU 高负载

上一篇:漏洞扫描工具nikto使用方法
下一篇:OpenLdap 搭建(Master Slave)、分组、热备及管理

分享到: 收藏
iTechClub广告