理解 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