High IO wait
Table of Contents
1 现象
top 命令，我们发现%wa 的值,达到20以上,甚至40以上，此时，我们就要明确，现在CPU 大量消耗在等待IO响应上了。请注意，是在等待IO响应，而不是在等待磁盘完成IO操作.
这两者之间的区别在于，等待IO响应， 可能链路没反应，请求根本没有到达磁盘，也有 可能磁盘损坏，无法响应，高IO wait 不一定代表磁盘很忙。
因此分析这种情况，我们需要从两个角度来考虑: 磁盘忙和磁盘不忙。磁盘不忙，但是 %wa 较高，唯一说明的问题就是:IO通道发生了异常。进程发送请求、信号传输、链路 传输、磁盘读取/写入、信号返回等各个步骤都有可能异常。所以%wa高，不一定是磁盘 达到了瓶颈。也有可能是链路或存储本身出现了问题,也有可能服务器参数配置不合理 导致进程无法发送消息。
2 分析
常用的分析工具有iotop,iostat. 一般想看哪个或者哪些磁盘上CPU等待比较高，会使用iostat, 而查找消耗IO较高的进程则使 用iotop. 那么如果我们查看哪些进程在等待IO响应,可以使用一行命令。下面来详细 说明:
2.1 iotop或者pidstat
2.1.1 iotop
iotop可以让我们很方便的找出哪个进程在消耗大量的IO资源。也就是统计出进程的IO量。 这个命令的统计结果，是真实的IO消耗的统计,一般排行在靠前的进程，说明消耗IO资源 较多。具体磁盘忙不忙，还要看IO吞吐量。 示例如下:
Total DISK READ : 0.00 B/s | Total DISK WRITE : 137.02 K/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 207.49 K/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 5965 be/4 adb 0.00 B/s 62.64 K/s 0.00 % 0.28 % postgres: wal writer process 5908 be/4 adb 0.00 B/s 15.66 K/s 0.00 % 0.00 % postgres: logger process 5952 be/4 adb 0.00 B/s 11.74 K/s 0.00 % 0.00 % postgres: logger process 5953 be/4 adb 0.00 B/s 15.66 K/s 0.00 % 0.00 % postgres: logger process 5967 be/4 adb 0.00 B/s 15.66 K/s 0.00 % 0.00 % postgres: stats collector process ........
输出结果以IO列做降序排列，固定的时间(默认1秒)间隔刷新一次结果。有了进程编号， 我们就可以很方便的分析，定位高IO产生的原因。 或者直接输入 iotop -boP 命令, 将 每秒输出一次IO统计和正在使用IO的进程。如果使用IO的进程较多，还是不加参数方便
不过有些环境，并没有安装iotop工具,那么我们怎么办？其实iotop命令，获取的数据就 是存储在/proc/<pid>/io文件中。比如:
#cat /proc/5977/io rchar: 29381 wchar: 4369248962 syscr: 29379 syscw: 96033 read_bytes: 0 write_bytes: 4369088512 cancelled_write_bytes: 0
我们完全可以通过自己写脚本来实现基本的统计，比如每秒哪个进程读写最高。
2.1.2 pidstat
pidstat 这个命令，也是可以用来做高IO等待的性能分析的。而且也非常方便实用。
我们可以通过 pidstat -d <interval> 来输出进程的消耗情况。
pidstat -d 1 1 12时56分51秒 PID kB_rd/s kB_wr/s kB_ccwr/s Command 12时56分53秒 3348 0.00 20.00 0.00 jbd2/dm-2-8 12时56分53秒 3679 0.00 6.00 0.00 rsyslogd 12时56分53秒 22903 0.00 724.00 0.00 ns-slapd 12时56分53秒 44188 0.00 18.00 0.00 java 12时56分53秒 47980 0.00 4.00 0.00 java
也可以进行条件判断，取出关心的数据。比如:
pidstat -dl| head -3;pidstat -dl |awk ‘{if ($4 >10 || $3 > 10) print $0}‘
这一行的本意是输出读或者写大于10K的进程，但是由于不同操作系统设置不同，读和写的列不一定是第3和第4列。 因此执行前，需要先确认。
- note
- pidstat -d 的输出，默认是以Pid 进行升序排列的。
2.2 脚本
等待I/O的进程通过处于uninterruptible sleep或D状态。通过这个特点，查找有问题 的进程。这行命令，找出来的进程，只能说明，进程在等待IO操作，但是并不能说明 磁盘本身已经达到瓶颈。但是从另外一个角度来讲，我们可以定准有问题的进程。
for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done
此命令，每5秒, 取一次结果.查询结果类似如下:
----- D 248 [jbd2/dm-0-8] ----- D 248 [jbd2/dm-0-8]
2.3 追踪进程
我们定位了等待IO请求的进程，如果确实是消耗了IO, 我们可以通过减少单位时间的 IO吞吐来解决，或者把数据分散到不同的时间段去处理。
如果进程只是在等待IO，并没有什么吞吐量，可以对进程进行追踪(strace/truss)或 者gdb调试。看看问题到底出现在哪里。 问题到底出在哪儿。