cpu iowait高排查的case

在之前的常见的Java问题排查方法一文中，没有写cpu iowait时的排查方法，主要的原因是自己之前也没碰到过什么cpu iowait高的case，很不幸的是在最近一周连续碰到了两起cpu iowait的case，通过这两起case让自己学习到了很多系统层面的知识，也许这些知识对于熟悉系统的人来说没什么，不过对于写Java的同学我觉得还是值得分享下（由于Java基本不用于存储类型的场景，所以通常来说碰到iowait高的机会会比其他几类问题更低很多）。

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

但通常而言，上面的方法只能算勉强解决了问题，但还是没有定位到程序里哪个地方有问题，甚至有可能重启仍然iowait很高，于是需要借助其他工具来进一步排查，所幸系统层面是有这样的工具，主要可通过blktrace/debugfs来定位到到底是读或写哪个（或哪些）文件造成了iowait高（这个方法主要学习自阿里集团内核组的伯瑜的一篇blog）。

在装上了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中执行后看到的为：
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中，执行后的结果为：
Block Inode number
18624359 18284971
而debugfs还提供了通过inode number找到具体的文件的功能，于是就好办了，继续执行debugfs -R ‘ncheck 18284971′，执行后看到类似如下的信息：
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的同学，在排查问题时对于各种系统工具、硬件层面的一些知识还是要有些了解，不一定要很深，但至少要知道，对于工具要会用。