目录
1、问题：2、排查：2.1 vmstat2.2 iostat2.3 iotop3、最后的话：另辟蹊径
1、问题：
最近在做日志的实时同步，上线之前是做过单份线上日志压力测试的，消息队列和客户端、本机都没问题，但是没想到上了第二份日志之后，问题来了：
集群中的某台机器 top 看到负载巨高，集群中的机器硬件配置一样，部署的软件都一样，，却单单这一台负载有问题，初步猜测可能硬件有问题了。
同时，我们还需要把负载有异常的罪魁祸首揪出来，到时候从软件、硬件层面分别寻找解决方案。
2、排查：
从 top 中可以看到load average 偏高，%wa 很高，%us 偏低：
从上图我们大致可以推断 IO 遇到了瓶颈，下面我们可以再用相关的 IO 诊断工具，具体的验证排查下。
PS：如果你对 top 的用法不了解，请参考：Linux 系统监控、诊断工具之 top命令详解
常用组合方式有如下几种：
2.1 vmstat
vmstat命令的含义为显示虚拟内存状态（“Viryual Memor Statics”），但是它可以报告关于进程、内存、I/O等系统整体运行状态。
它的相关字段说明如下：
Procs（进程）
r: 运行队列中进程数量，这个值也可以判断是否需要增加CPU。（长期大于1）b: 等待IO的进程数量，也就是处在非中断睡眠状态的进程数，展示了正在执行和等待CPU资源的任务个数。当这个值超过了CPU数目，就会出现CPU瓶颈了
Memory（内存）
Swap（交换区）
si: 每秒从交换区写到内存的大小，由磁盘调入内存。so: 每秒写入交换区的内存大小，由内存调入磁盘。
注意：内存够用的时候，这2个值都是0，如果这2个值长期大于0时，系统性能会受到影响，磁盘IO和CPU资源都会被消耗。有些朋友看到空闲内存（free）很少的或接近于0时，就认为内存不够用了，不能光看这一点，还要结合si和so，如果free很少，但是si和so也很少（大多时候是0），那么不用担心，系统性能这时不会受到影响的。
IO（输入输出）
（现在的Linux版本块的大小为1kb）
bi: 每秒读取的块数bo: 每秒写入的块数
注意：随机磁盘读写的时候，这2个值越大（如超出1024k)，能看到CPU在IO等待的值也会越大。
system（系统）
in: 每秒中断数，包括时钟中断。cs: 每秒上下文切换数。
注意：上面2个值越大，会看到由内核消耗的CPU时间会越大。
CPU
（以百分比表示）
从 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 而造成所谓的”非中断睡眠“，我们可以从这点入手然后一步步的定位问题：
本文永久更新链接地址：
变幻原是永恒，我们唯有用永恒的诺言制约世事的变幻。
