理解 IO_WAIT 并且了解利用包括 top htop iotop iostat 工具来查看 IO 性能

今天继续拜读「深入浅出计算机组成原理」专栏，觉得讲 IO_WAIT 这篇很有意思，正好可以结合前面的一篇讲物理硬件存速度的一块儿看。

现在我们看硬盘厂商出品的性能报告，通常会看到两个指标，一个是响应时间(Response Time) 另外一个是 数据传输速率 (Data Transfer Rate) 。

目前硬盘分两种，一种是 HDD 硬盘，也就是传统的机械硬盘.使用的是传统的 SATA3.0 的接口，而另外一种是 SSD 盘，也就是现在被我们成为固态硬盘的东西。它既可以使用 SATA3.0 接口，还可以使用另外一种叫做 PCI EXPRESS 的接口（以下称为 PCI 接口）。这里要补充一下 PCI 接口的吞吐率大幅高于 SATA3.0 的接口。 使用 SATA3.0 口的固态硬盘可能面临 接口的传输速率极限而限制了硬盘本身读写速度的发挥。

现在我们 SATA3.0 的贷款大致是 6Gbit/s 也就是 6 * 1024 / 8  约768 MB/s 的速度。这是一个很高的理论带宽值，根据专栏提供的数据，我们平时使用传输速率差不多只有 200MB/s

这里我插入一个 访问延时的比较图

 

这是我们平时经常接触的存储器的访问延时情况，可以看到 上面提到的 HDD 和 SSD 盘是最便宜的两种，随机访问延时 SSD  差不多是 150 微秒， HDD 则已经到毫秒级别。速度越快的存储，存量越小，越贵。

 

下面我们继续回到 HDD 和 SSD 这种通用外部存储上来。这里有一张使用 PCI 接口的 SSD 传输图

 

第一行参数 Seq 代表 SSD 进行顺序读写时候的速度，可以看到 - - 真是非常快啊。

第二行 4k 代表对 4k 大小文件进行随机读写的效率。可以看到- - 真是非常慢啊，对比 seq 的速度真是慢了不知道多少。

第三行 4K-64 64thrd表示多线程并发操作的性能，一般个人使用情况下不会用到如此多线程，一般也就qd=3，但是这个指标对服务器应用很重要。

第四行 acc代表我们之前说的响应时间可以看到 0.066ms ，还记得我们上面的随机读取延时图吗，就跟这个时间差不多。

 

另外还有一个指标也是衡量吞吐量很重要的指标， IOPS（每秒读写次数）

比如随机读写，我们随机读性能是 40MB/S 那么我们读 4kb 文件

40*1024 / 4 ～= 10000 IOPS 写入差不多 20000

因为我们在实际应用的开发中，对于数据的访问，更多的是随机读写，而不是顺序读写。我们平时说的服务器承受的 “并发”，其实是在说，会有很多个不同的进程和请求来访问服务器。自然，它们在硬盘上访问的数据，是很难顺序放在一起的。在这种情况下，随机读写的 IOPS 才是服务器性能的核心指标。

根据专栏给出的数据，正常的 HDD IOPS 仅有 100 左右。

这个 100 应该是这么计算的，首先我们假设是一个 每分钟 7200 转的 HDD 盘

在随机读取的情况下，每转半圈大概可以找到一个目标几何区 也就是每分钟可以转 240 个半圈

1s/240 = 4.17 这是平均延时(Average Latency)

另外我们还需要进行寻道，在盘面旋转之后我们悬臂定位到指定扇区的时间，现在 HDD 盘平均寻道时间在 4-10ms

所以我们平均每 4.17 + 4 - 4.17 + 10 = 8 - 14 ms 完成一次数据存取。

那么对应 IOPS 就是 70 - 125 ，平均一下 100 就是这么来的。

 

上面介绍了那么多如何衡量硬盘的读写，下面我们来回归到主题，如何定位 IO_WAIT

使用

top

top - 06:26:30 up 4 days, 53 min,  1 user,  load average: 0.79, 0.69, 0.65
Tasks: 204 total,   1 running, 203 sleeping,   0 stopped,   0 zombie
%Cpu(s): 20.0 us,  1.7 sy,  0.0 ni, 77.7 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st
KiB Mem:   7679792 total,  6646248 used,  1033544 free,   251688 buffers
KiB Swap:        0 total,        0 used,        0 free.  4115536 cached Mem

第三行 wa 就代表 cpu 的 io_wait 情况。这里可以用把这些简写都大概介绍一下

us：用户占用 cpu 比例

sy：内核空间占用 cpu 比例

ni：用户进程空间内改变过优先级的进程占用CPU百分比

id：空闲CPU百分比

wa: 等待 io 的 cpu 时间占比

hi：硬件中断

si：软件中断

st: 不知道是啥- - 不知道做什么用

 

如果我们看到 wa 非常高，说明 cpu 等待 io 的情况比较严重。如果我们发现了 wa 很高可以继续执行 iostat 查看详情。

iostat

Linux 3.10.0-514.21.1.el7.x86_64 (iZ2ze3vworsqn8xb3m9zn5Z)     09/26/2019     _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.02    0.00    0.59    0.21    0.00   98.18

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
vda              18.59        29.85       200.15 1033068029 6926347580
vdb               0.23         5.13        78.92  177419637 2731053200

这是一台我部署了 kafka 的机器执行 iostat 的情况。

可以看到 iowait 的情况，以及单个磁盘 tps(iops)的情况。这时候我们要找出到底是哪个程序这么吃 io 我们使用

iotop

注意 iotop 在 CentOS7.X 版本上好像不是默认安装的，可以安装一下 yum -i install iotop

Total DISK READ :       0.00 B/s | Total DISK WRITE :      15.75 K/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:      35.44 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                             
  104 be/3 root        0.00 B/s    7.88 K/s  0.00 %  0.18 % [jbd2/sda1-8]
  383 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % rsyslogd -n [rs:main Q:Reg]
 1514 be/4 www-data    0.00 B/s    3.94 K/s  0.00 %  0.00 % nginx: worker process

如果有应用一直在前排 且 IO> 一直非常大，我们可以从 COMMAND 列定位到该程序进行查看。

 以上。

 

 

Ref:

https://blog.csdn.net/Sasoritattoo/article/details/9318893    CPU状态信息us,sy,ni,id,wa,hi,si,st含义

https://serverfault.com/questions/155882/wa-waiting-for-i-o-from-top-command-is-big    wa (Waiting for I/O) from top command is big

https://time.geekbang.org/column/article/113809    极客时间「深入浅出计算机组成原理」44讲「理解 IO_WAIT」: I/O 性能到底是怎么回事儿？

https://en.wikipedia.org/wiki/IOPS