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

时间 2019-11-11

标签 linux 系统监控诊断工具 wait 栏目 Linux 繁體版

原文原文链接

一、问题：

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

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

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

二、排查：

从 top 中能够看到 load average 偏高，%wa 很高，%us 偏低：算法

从上图咱们大体能够推断 IO 遇到了瓶颈，下面咱们能够再用相关的 IO 诊断工具，具体的验证排查下。缓存

PS：若是你对 top 的用法不了解，请参考我去年写的一篇博文：性能优化

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

经常使用组合方式有以下几种：网络

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

2.1 vmstat

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

它的相关字段说明以下：

Procs（进程）
• r: 运行队列中进程数量，这个值也能够判断是否须要增长CPU。（长期大于1）
• b: 等待IO的进程数量，也就是处在非中断睡眠状态的进程数，展现了正在执行和等待CPU资源的任务个数。当这个值超过了CPU数目，就会出现CPU瓶颈了

Memory（内存）
• swpd: 使用虚拟内存大小，若是swpd的值不为0，可是SI，SO的值长期为0，这种状况不会影响系统性能。
• free: 空闲物理内存大小。
• buff: 用做缓冲的内存大小。
• cache: 用做缓存的内存大小，若是cache的值大的时候，说明cache处的文件数多，若是频繁访问到的文件都能被cache处，那么磁盘的读IO bi会很是小。

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（以百分比表示）
• us: 用户进程执行时间百分比(user time)
us的值比较高时，说明用户进程消耗的CPU时间多，可是若是长期超50%的使用，那么咱们就该考虑优化程序算法或者进行加速。
• sy: 内核系统进程执行时间百分比(system time)
sy的值高时，说明系统内核消耗的CPU资源多，这并非良性表现，咱们应该检查缘由。
• wa: IO等待时间百分比
wa的值高时，说明IO等待比较严重，这可能因为磁盘大量做随机访问形成，也有可能磁盘出现瓶颈（块操做）。
• id: 空闲时间百分比

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

2.2 iostat

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

它的相关字段说明以下：

rrqm/s:    每秒进行 merge 的读操做数目。即 delta(rmerge)/s
wrqm/s:    每秒进行 merge 的写操做数目。即 delta(wmerge)/s
r/s:       每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s:       每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s:    每秒读扇区数。即 delta(rsect)/s
wsec/s:    每秒写扇区数。即 delta(wsect)/s
rkB/s:     每秒读K字节数。是 rsect/s 的一半，由于每扇区大小为512字节。(须要计算)
wkB/s:     每秒写K字节数。是 wsect/s 的一半。(须要计算)
avgrq-sz:  平均每次设备I/O操做的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:  平均I/O队列长度。即 delta(aveq)/s/1000 (由于aveq的单位为毫秒)。
await:     平均每次设备I/O操做的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm:     平均每次设备I/O操做的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util:     一秒中有百分之多少的时间用于 I/O 操做，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (由于use的单位为毫秒)

能够看到两块硬盘中的 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来取代传统的机械硬盘。
不过前面也说了，咱们从软硬件两方面着手的目的就是看可否分别寻求代价最小的解决方案：

知道硬件的缘由了，咱们能够尝试把读写操做移到另外一块盘，而后再看看效果：

三、最后的话：另辟蹊径

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

咱们知道进程有以下几种状态：

PROCESS STATE CODES
 D uninterruptible sleep (usually IO)
 R running or runnable (on run queue)
 S interruptible sleep (waiting for an event to complete)
 T stopped, either by a job control signal or because it is being traced.
 W paging (not valid since the 2.6.xx kernel)
 X dead (should never be seen)
 Z defunct ("zombie") process, terminated but not reaped by its parent.

其中状态为 D 的通常就是因为 wait IO 而形成所谓的”非中断睡眠“，咱们能够从这点入手而后一步步的定位问题：

for x in `seq 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done
 D 248 [jbd2/dm-0-8]
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----
 D 22 [kdmflush]
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----
# 或者：
while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
 Tue Aug 23 20:03:54 CLT 2011
 root       302  0.0  0.0      0     0 ?        D    May22   2:58  \_ [kdmflush]
 root       321  0.0  0.0      0     0 ?        D    May22   4:11  \_ [jbd2/dm-0-8]
 Tue Aug 23 20:03:55 CLT 2011
 Tue Aug 23 20:03:56 CLT 2011

cat /proc/16528/io
 rchar: 48752567
 wchar: 549961789
 syscr: 5967
 syscw: 67138
 read_bytes: 49020928
 write_bytes: 549961728
 cancelled_write_bytes: 0
 
lsof -p 16528
 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
 bonnie++ 16528 root cwd DIR 252,0 4096 130597 /tmp
 <truncated>
 bonnie++ 16528 root 8u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 9u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 10u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 11u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 12u REG 252,0 501219328 131869 <strong>/tmp/Bonnie.16528</strong>
 
df /tmp
 Filesystem 1K-blocks Used Available Use% Mounted on
 /dev/mapper/workstation-root 7667140 2628608 4653920 37% /
 
fuser -vm /tmp
        USER        PID ACCESS COMMAND
 /tmp:  db2fenc1   1067 ....m db2fmp
        db2fenc1   1071 ....m db2fmp
        db2fenc1   2560 ....m db2fmp
        db2fenc1   5221 ....m db2fmp

四、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命令实战详解

http://www.cnblogs.com/ggjucheng/archive/2012/01/05/2312625.html
[6] 影响Linux服务器性能的因素

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

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

http://blog.csdn.net/qiudakun/article/details/4699587

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

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