Linux 高 wio 分析

High IO wait

Table of Contents

• 1. 现象
• 2. 分析
  • 2.1. iotop或者pidstat
    • 2.1.1. iotop
    • 2.1.2. pidstat
  • 2.2. 脚本
  • 2.3. 追踪进程

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调试。看看问题到底出现在哪里。 问题到底出在哪儿。

Author: halberd.lee@gmail.com

Created: 2020-04-29 Wed 17:49

Validate