当前位置: 首页 > Java > 正文

cpu iowait高排查的过程

关键字:
1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

当出现iowait高时,最重要的是要先找出到底哪个进程在消耗io,以最快的速度解决问题,但linux默认的一些工具例如像top、iostat等都只能看到io的消耗状况,但对应不到是哪个进程在消耗,比较好用的用来定位的工具是iotop,不过有些环境要装上可能不太容易,装上了后直接执行iotop,就可以看到到底是哪个进程消耗了比较多的io,对应解决问题而言,通常在找到进程后杀掉基本就算解决了(还有一种方法是通过打开syslog以及blk_dump来看一段时间内消耗io的进程,但在我的两个case里试过效果不太理想)。

但通常而言,上面的方法只能算勉强解决了问题,但还是没有定位到程序里哪个地方有问题,甚至有可能重启仍然iowait很高,于是需要借助其他工具来进一步排查,所幸系统层面是有这样的工具,主要可通过blktrace/debugfs来定位到到底是读或写哪个(或哪些)文件造成了iowait高.

在装上了blktrace后,先mount -t debugfs none /sys/kernel/debug下,然后可通过iostat查看到底是哪个设备在消耗io,例如假设看到是sda在消耗,那么即可执行blktrace /dev/sda,在执行时将会自动在执行的目录下生成一些sda.blktrace.*的文件,当觉得采集的差不多后,即可ctrl+c停掉。

之后执行blkparse sda.blktrace.* > result.log,再生成了result.log后执行grep ‘A’ result.log | head -n 5看看在采集的这段过程中,消耗io比较多的地方在哪,例如在我碰到的case中执行后看到的为:

1
2
3
4
5
8,0 11 1 0.000071219 248366 A R 218990140 + 16 <- (8,9) 148994872
8,0 11 1 0.000071219 248366 A R 218990140 + 16 <- (8,9) 148994872
8,0 11 1 0.000071219 248366 A R 218990140 + 16 <- (8,9) 148994872
8,0 11 1 0.000071219 248366 A R 218990140 + 16 <- (8,9) 148994872
8,0 11 1 0.000071219 248366 A R 218990140 + 16 <- (8,9) 148994872

这里A后面的R到底的意思是读(如果是写则为WS),和之前iostat看到的是一样的,io主要是大量的读造成的。

通过上面的信息8,0和(8,9)可以看到主要的消耗是在sda9(这个通过iostat也可以看到),(8,9)后的148994872代表读的扇区号。

再通过debugfs -R ‘stats’ /dev/sda9 | grep ‘Block size’可以找到sda9的block size,在我碰到的case中block size是4096,也是通常ext2/ext3文件系统默认的。

每个扇区的大小为512,148994872/(4096/512) = 18624359即可找到文件系统上对应的block号,之后通过debugfs -R ‘icheck 18624359′ /dev/sda9可找到对应的inode,在我碰到的case中,执行后的结果为:

1
2
Block Inode number
18624359 18284971

而debugfs还提供了通过inode number找到具体的文件的功能,于是就好办了,继续执行debugfs -R ‘ncheck 18284971′,执行后看到类似如下的信息:

1
2
Inode Pathname
18284971 [相应的文件名]

在找到了文件名后就好办了,可结合之前的iotop或直接lsof找出对应的进程id,然后就可以看看从代码上层面怎么避免对此文件的大量读。

除了上面的这种case外,还有些情况的iowait其实是比较简单的,例如读写了巨大的文件(通常在大量出现异常时可能会出现)…

在解决上周碰到的两个cpu iowait高的case中,其中一个是如上面的业务代码造成,但另一个则是和raid卡配置相关,因为从iostat来看,当时写的量也不是很大,但iowait却比较高,请系统的人帮忙看了后,告诉我是因为raid卡写策略配置的问题,我之前对raid卡的这些配置完全不懂。

通过服务器上会带有raid卡,而现在的raid卡基本是带有cache的,为了保障cache里的数据的安全性,通常raid卡会带有电池或电容,相对而言电容的故障率比较低,raid卡会提供写策略的配置,写策略通常是Write Back和Write Through两种,Wirte Back是指写到cache后即认为写成功,Write Through是指写到磁盘上才算成功,通常Raid卡的写策略会分为正常时,以及电池或电容出问题时两种来配置,而在碰到的case中是因为配置了当电池/电容出问题时采用Write Through,当时机器的Raid卡的电池出故障了,所以导致策略切换为了Write Through,能够支撑的iops自然是大幅度下降了,而在我们的场景中,本地数据丢掉是无所谓的,所以Raid卡的策略可以配置为即使电池出故障了也仍然采用Write Back。

通常各种Raid卡都会提供工具来配置写策略,例如HP卡的hpacucli,可通过cat /proc/scsi/scsi查看硬盘和Raid卡的信息(可以先用cat /proc/mdstat来查看raid信息),有助于确认raid卡的cache/cache容量/电池以及硬盘本身能支撑的iops等。

因为建议在碰到iowait高的场景时,可以先看看raid卡的写策略,如果没问题的话再通过iotop、blktrace、debugfs、lsof等来定位到具体的根源。

可见即使是对于Java的同学,在排查问题时对于各种系统工具、硬件层面的一些知识还是要有些了解,不一定要很深,但至少要知道,对于工具要会用。

本文固定链接: http://www.chepoo.com/cpu-iowait-high-case.html | IT技术精华网

cpu iowait高排查的过程:等您坐沙发呢!

发表评论