linux 系统监控、诊断工具之 IO wait

linux 系统监控、诊断工具之 IO wait

原文地址： /article/2204325.html 作者：xrzs

目录[-]

1、问题：

2、排查：

2.1 vmstat

2.2 iostat

2.3 iotop

3、最后的话：另辟蹊径

4、Refer：

1、问题：

最近在做日志的实时同步，上线之前是做过单份线上日志压力测试的，消息队列和客户端、本机都没问题，但是没想到上了第二份日志之后，问题来了：

集群中的某台机器 top 看到负载巨高，集群中的机器硬件配置一样，部署的软件都一样，却单单这一台负载有问题，初步猜测可能硬件有问题了。

同时，我们还需要把负载有异常的罪魁祸首揪出来，到时候从软件、硬件层面分别寻找解决方案。

2、排查：

从 top 中可以看到 load average 偏高，%wa 很高，%us 偏低：





从上图我们大致可以推断 IO 遇到了瓶颈，下面我们可以再用相关的 IO 诊断工具，具体的验证排查下。

PS：如果你对 top 的用法不了解，请参考我去年写的一篇博文：

linux
系统监控、诊断工具之 top 详解

常用组合方式有如下几种：

用vmstat、sar、iostat检测是否是CPU瓶颈
用free、vmstat检测是否是内存瓶颈
用iostat、dmesg 检测是否是磁盘I/O瓶颈
用netstat检测是否是网络带宽瓶颈

2.1 vmstat

vmstat命令的含义为显示虚拟内存状态（“Virtual Memor Statics”），但是它可以报告关于进程、内存、I/O等系统整体运行状态。

vmstat -t 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---

r b swpd free buff cache si so bi bo in cs us sy id wa st

22 0 0 43954816 44876 18886960 0 0 2 125 31 130 78 1 21 0 0 2015-03-04 15:31:36 CST

19 0 0 43953324 44876 18887632 0 0 0 14340 16773 11832 94 0 6 0 0 2015-03-04 15:31:37 CST

23 0 0 43952848 44876 18888260 0 0 0 0 16146 10690 92 1 8 0 0 2015-03-04 15:31:38 CST

vmstat 2 5





它的相关字段说明如下：

?
从 vmstat 中可以看到，CPU大部分的时间浪费在等待IO上面，可能是由于大量的磁盘随机访问或者磁盘的带宽所造成的，bi、bo 也都超过 1024k，应该是遇到了IO瓶颈。

2.2 iostat

下面再用更加专业的磁盘 IO 诊断工具来看下相关统计数据。





它的相关字段说明如下：

?
可以看到两块硬盘中的 sdb 的利用率已经 100%，存在严重的 IO 瓶颈，下一步我们就是要找出哪个进程在往这块硬盘读写数据。

2.3 iotop

根据 iotop 的结果，我们迅速的定位到是 flume 进程的问题，造成了大量的 IO wait。

但是在开头我已经说了，集群中的机器配置一样，部署的程序也都 rsync 过去的一模一样，难道是硬盘坏了？

这得找运维同学来查证了，最后的结论是：

Sdb为双盘raid1，使用raid卡为“LSI Logic / Symbios Logic SAS1068E”，无cache。近400的IOPS压力已经达到了硬件极限。而其它机器使用的raid卡是“LSI Logic / Symbios Logic MegaRAID SAS 1078”，有256MB
cache，并未达到硬件瓶颈，解决办法是更换能提供更大IOPS的机器，比如最后我们换了一台带 PERC6/i 集成RAID控制器卡的机器。需要说明的是，raid信息是在raid卡和磁盘固件里面各存一份，磁盘上的raid信息和raid卡上面的信息格式要是匹配的，否则raid卡识别不了就需要格式化磁盘。

IOPS本质上取决于磁盘本身，但是又很多提升IOPS的方法，加硬件cache、采用RAID阵列是常用的办法。如果是DB那种IOPS很高的场景，现在流行用SSD来取代传统的机械硬盘。

不过前面也说了，我们从软硬件两方面着手的目的就是看能否分别寻求代价最小的解决方案：

知道硬件的原因了，我们可以尝试把读写操作移到另一块盘，然后再看看效果：

3、最后的话：另辟蹊径

其实，除了用上述专业的工具定位这个问题外，我们可以直接利用进程状态来找到相关的进程。

我们知道进程有如下几种状态：

?
其中状态为 D 的一般就是由于 wait IO 而造成所谓的”非中断睡眠“，我们可以从这点入手然后一步步的定位问题：

?

4、Refer：

[1] Troubleshooting High I/O Wait in Linux

——A walkthrough on how to find processes that are causing high I/O Wait on Linux Systems

http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/

[2] 理解Linux系统负荷

http://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html

[3] 24 iostat, vmstat and mpstat Examples for Linux Performance Monitoring

http://www.thegeekstuff.com/2011/07/iostat-vmstat-mpstat-examples/

[4] vmstat vmstat命令

http://man.linuxde.net/vmstat

[5] Linux vmstat命令实战详解

/article/4630429.html

[6] 影响Linux服务器性能的因素

http://www.rocklv.net/2004/news/article_284.html

[7] linux磁盘IO查看iostat,vmstat

/article/10132258.html

[8] What Process is using all of my disk IO

http://stackoverflow.com/questions/488826/what-process-is-using-all-of-my-disk-io

[9] Linux Wait IO Problem

http://www.chileoffshore.com/en/interesting-articles/126-linux-wait-io-problem

[10] Tracking Down High IO Wait in Linux

http://ostatic.com/blog/tracking-down-high-io-wait-in-linux

[11] 磁盘IOPS计算与测量

/article/2433927.html

[12] [DOC]磁盘性能指标—IOPS - Huawei

http://www.huawei.com/ecommunity/3msimage/download-10053641-10023111-fbcd1a056196d26a1a30032a222a5ec3.bin?type=bbs

[13] RAID卡

http://baike.baidu.com/view/95439.htm