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的同学,在排查问题时对于各种系统工具、硬件层面的一些知识还是要有些了解,不一定要很深,但至少要知道,对于工具要会用。 ------------微信互动------------ 1. 在设置LANG即可改变Java的默认编码的原因分析的那篇文章发出后,有同事给我反馈其中的这段话:“顺带说一句,其实即使在启动时带上-Dfile.encoding也不会改变Charset.defaultCharset(这个默认编码还是以LC_CTYPE为准),加上这个参数只会改变系统属性中的file.encoding值而已。” 和他测试时的表现不一致,后来我确认才发现这段话是我过于武断的判断了,在这里要纠正为“,-Dfile.encoding是可以生效的,只是在指定的file.encoding没有对应的Charset实现时,会默认为UTF-8,这里要稍微注意的一点是,file.encoding的指定方法和LANG有些不同,LANG通常的语言大集.小集,例如zh_CN.gbk,而file.encoding就直接是语言的小集,例如gbk。“。 问: String.intern那篇文章里关于s1 == s2的那个case,为什么要保证s1.intern是在String s2赋值的那行之前,因为如果String s2赋值是在s1.intern之后,那么即使是在jdk 7中s1 == s2也会是false。 答: 这里的原因是在JDK 7中,当执行String.intern时,如String Pool中没有相同内容的,则会将此内容作为key,而value即为此String对象,在对String进行赋值时,会先在String pool中找是否会相同内容的,有的话则直接就指向改对象,没有就新创建一个对象,因此在那篇文章的case里,如果在String s2赋值之前执行s1.intern,那么String pool里就已经有了”GoodMorning“对应的String对象实例了,也就是s1,因此之后在执行String s2 = "GoodMorning"时,就已经是直接将s1赋给了s2,但调转这行代码后就不一样了。 问:你说之前那个cpu us诡异的case的根本原因是BeanUtils里频繁调用Class.getMethod造成的,那不是很容易出现这个现象? 答:其实出现这个现象不会太容易,原因是如果传入的methodName基本是固定的,那么其实执行String.intern真正放进String pool的并不会多,而在我之前碰到的case里为什么有问题,原因是类似struts之类的结构,通常是会把一个form里的所有域直接填充到对应的对象里去,而如果form里有一些隐藏域,是和每次请求有关的话,那么BeanUtils在执行class.getMethod时传入的methodName可能就是经常变化的,如果这个页面访问量又比较大的话,那就很容易导致String pool性能疯狂下降,建议最好是在用BeanUtils填充对象时,先检查下是否有必要。 ============================= 欢迎关注微信公众号:hellojavacases 关于此微信号: 用于分享Java的一些小知识点,Java问题排查的Cases,Java业界的动态,以及和大家一起互动讨论一些Java的场景和问题。 公众号上发布的消息都存放在http://hellojava.info上。