说明
%iowait, await, %util 是用来衡量硬盘负载的三个指标, 但是这几个指标通常容易被误解, 实际上, 这三个指标单纯的高, 并不一定能说明相应的磁盘有问题或者有瓶颈, 而是需要结合具体执行 IO 操作的程序的执行方式, 综合的来判断指标高的原因.
关于 await, %util 的计算方式可以参照:
linux iostat 输出详解
总结
%iowait:
最容被误解的参数, 实际上这是一个非常宏观的系统指标, 其表示 "CPU空闲 并且 有未完成的IO " 这种状态在一个采样周期里的占比, 一般来说当一个进程进行同步的 IO 操作时, 进程将会被挂起, CPU 将会空闲, 等待 IO 完成, 这时候如果没有其它进程占用 CPU 此时的状态将会被计入 iowait 的统计时间以内. 但是 CPU 空闲也只是当前进程空闲, 空闲出来的 CPU 是可以进行其它操作的, 如果此时 %iowait 较高, 只能说明在等待 IO 完成的时间里系统没有其它进程来占用 CPU 了, 而 IO 未完成, 有可能只是单纯的 IO size 比较大, 完成需要较长时间, 并不一定是 IO 有问题.
而且如果等待 IO 完成时系统有其它繁忙的进程占用了 CPU, 那么无论此时 IO 完成时间多长(即使是IO完全卡死), %iowait 也会非常的低, 因为此时CPU不空闲了, 因为 %iowait 只是反映 "CPU空闲 并且 有未完成的IO " 这种状态时间的占比, 两个条件缺少一个都不会计入 iowait 的时间.
await
每个I/O的平均耗时, 包括在内核 IO 队列内的时间和在存储设备上执行此 IO 的时间, 所以 await 高可能有两个原因, 一是 IO 在 IO queue 里耗时较长, 另一个就是由于 IO 在存储设备上执行的时间比较长, 而 IO 在 IO queue 里耗时较长可能是由于程序一次并发了过多的 IO, 让 IO 在 queue 排队, IO 在存储设备上执行的时间比较长也有可能时 IO 本身就比较大, 例如在硬盘上写 1KB 文件, 耗时一定是比 1MB的时间短的, 所以 await 高, 还要结合业务本身的特点判断 await 高的原因
%util
这个反映 IO queue, 中存在 IO 在采样周期里的占比, 只要 IO queue 中存在 IO, 就会被计入到 %util 的时间内, 无论是 1 个 IO 或者 100 个IO, 并且也只计算 IO 存在于 queue 里面的时间, 所以此时即使磁盘压力较大, 但是 IO queue 中并没有排队的 IO 那么 %util 也不会高(例如每次 IO size 都比较大), 或者有些程序进行顺序 IO, 完成几个再发下一个, 并且 IO size 并不大, 此时即使磁盘压力较小 %util 也会比较高
测试
环境和命令
使用 fio 模拟客户端, 通过不同的 fio 引擎和不同的队列深度配置来模拟顺序的和并发的 IO
环境如下
[root@centos-76-c1~]# uname -a
Linux centos-76-c1 5.5.7-1.el7.elrepo.x86_64 #1 SMP Fri Feb 28 12:21:58 EST 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@centos-76-c1~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
[root@centos-76-c1~]# fio --version
fio-3.1
使用 iostat -mx 1 10000 sdb 来模监控 %iowait, await , %util 具体数值
[root@centos-76-c1~]# iostat -mx 1 10000 sdb
Linux 5.5.7-1.el7.elrepo.x86_64 (centos-76-c1) 03/05/2020 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
1.46 0.00 0.78 12.33 0.00 85.43
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.66 0.60 263.41 0.01 1.17 9.20 21.27 81.06 7.02 81.23 0.16 4.23
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 0.00 0.00 0.00 100.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
......
%iowait
%iowait 与 CPU 本身的关系
找一个 CPU 空闲的时期
[root@centos-76-c1~]# top -n 1
top - 17:38:33 up 1:02, 3 users, load average: 0.00, 0.10, 0.12
Tasks: 136 total, 1 running, 81 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 977804 total, 696812 free, 105696 used, 175296 buff/cache
KiB Swap: 1572860 total, 1572860 free, 0 used. 697424 avail Mem
随便增加一些负载差不多的普通负载, 观察此时的 iowait
[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=16k --size=1G --runtime=60 --ramp_time=20 --ioengine=sync --numjobs=1 --filename=/dev/sdb --direct=1 --group_reporting
randwrite: (g=0): rw=randwrite, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=sync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][r=0KiB/s,w=1472KiB/s][r=0,w=92 IOPS][eta 00m:00s]
randwrite: (groupid=0, jobs=1): err= 0: pid=7724: Thu Mar 5 17:56:42 2020
write: IOPS=86, BW=1390KiB/s (1423kB/s)(81.5MiB/60004msec)
clat (usec): min=2917, max=48358, avg=11505.79, stdev=4808.19
lat (usec): min=2918, max=48359, avg=11506.34, stdev=4808.19
.....
iowait 达到了 99%
......
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 1.00 99.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 101.00 0.00 1.58 32.00 0.94 9.86 0.00 9.86 1.02 10.30
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 0.00 100.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 97.96 0.00 1.53 32.00 0.97 10.41 0.00 10.41 1.02 10.00
......
此时增加一个十分耗费 CPU 的计算圆周率的命令, 计算 50000 位的圆周率
[root@centos-76-c1~]# time echo "scale=50000; 8*a(1)" | bc -l -q
- 1
此时 CPU 利用率已经非常高
[root@centos-76-c1~]# top -n 1
top - 17:59:21 up 1:22, 3 users, load average: 0.21, 0.17, 0.09
Tasks: 138 total, 2 running, 81 sleeping, 0 stopped, 0 zombie
%Cpu(s):100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 977804 total, 696652 free, 105816 used, 175336 buff/cache
KiB Swap: 1572860 total, 1572860 free, 0 used. 697288 avail Mem
这是可以看到 %iowait 直接变成了 0.00
......
avg-cpu: %user %nice %system %iowait %steal %idle
100.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 66.00 0.00 1.03 32.00 0.66 10.48 0.00 10.48 1.98 13.10
avg-cpu: %user %nice %system %iowait %steal %idle
99.01 0.00 0.99 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 69.31 0.00 1.08 32.00 0.66 10.11 0.00 10.11 2.00 13.86
......
总结
通过上面的测试可以证明 %iowait 是一个十分宏观的一个参数, 系统其他服务对 CPU 的利用会直接影响这个数值, 如果 CPU 利用率够高, 即使此时 IO 完全卡死, 此时 %iowait 可能也很低. %iowait 即使很高, 实际上硬盘的压力可能也不大.
await
await 和 iodepth 的关系
使用 fio 模拟客户端, 固定大小的 io 请求, 通过配置不同的 --iodepth= --iodepth_batch_submit= --iodepth_low= 来实现不同并发度的 IO
[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=4k --size=1G --runtime=60 --ramp_time=20 --ioengine=libaio --iodepth=<iodepth> --iodepth_batch_submit=<iodepth> --iodepth_low=<iodepth> --numjobs=1 --filename=/dev/sdb --direct=1 --group_reporting
测试结果
| iodepth | IOPS | BW | avgqu-sz | await |
|---|---|---|---|---|
| 1 | 90 | 363KiB/s | 0.20 | 3.03 |
| 4 | 337 | 1349KiB/s | 2.17 | 6.51 |
| 16 | 1168 | 4676KiB/s | 10.00 | 7.50 |
| 64 | 1828 | 7317KiB/s | 47.97 | 18.33 |
| 256 | 1851 | 7424KiB/s | 252.03 | 300 ~ 500 |
| 1024 | 1723 | 6963KiB/s | 270.84 | 300 ~ 600 |
总结
随着并发度越来越高, 达到了本机 IO 能承受的 IO 的上限, 大量 IO 在存储集群里面排队, 可以看到 await 随着 IO 在队列中排队时间的增大而逐渐增大
await 和 iosize 的关系
使用 fio 模拟客户端, 固定大小的 io iodept, 通过配置不同的 --bs=<block_size> 来实现不同<block_size>的 IO (block_size 即一次读写的文件的大小)
[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=<block_size> --size=1G --runtime=60 --ramp_time=20 --ioengine=libaio --iodepth=1 --iodepth_batch_submit=1 --iodepth_low=1 --numjobs=1 --filename=/dev/sdb --direct=1 --group_reporting
- 1
测试结果
| block_size | IOPS | BW | avgrq-sz | avgqu-sz | await |
|---|---|---|---|---|---|
| 4KiB | 90 | 364KiB/s | 8.00 | 0.25 | 2.93 |
| 16KiB | 69 | 1120KiB/s | 32.00 | 0.64 | 9.75 |
| 64KiB | 30 | 1948KiB/s | 128.00 | 0.84 | 30.11 |
| 256KiB | 11 | 3004KiB/s | 512.00 | 0.93 | 89.90 |
| 1MiB | 4 | 4168KiB/s | 2048.00 | 1.14 | 227.00 |
| 4MiB | 1 | 4531KiB/s | 2048.00 - 2560.00 | 3.46 | 902.75 |
| 16MiB | 0 | 5206KiB/s | 2048.00 - 2560.00 | 12.50 | 2223.40 |
总结
可以看到随着 block_size 即 一次读写的文件的大小不断增加, await 也逐渐增加, 实际上此时 IO 并不能说 IO 是瓶颈, 或者 IO 延时过高, 只是单纯的完成大 IO 耗时更长
%util
%util 与 IO 的关系
使用 fio 分别测试不同 iosize 的同步 IO
[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=4K --size=1G --runtime=60 --ramp_time=20 --ioengine=sync --numjobs=4 --filename=/dev/sdb --direct=1 --group_reporting --sync=1
randrw: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1
...
fio-3.1
Starting 4 processes
Jobs: 2 (f=2): [E(0),w(4)][100.0%][r=0KiB/s,w=1081KiB/s][r=0,w=270 IOPS][eta 00m:00s]
randrw: (groupid=0, jobs=4): err= 0: pid=8310: Thu Mar 5 19:24:57 2020
write: IOPS=292, BW=1169KiB/s (1197kB/s)(68.5MiB/60004msec)
......
......
Davg-cpu: %user %nice %system %iowait %steal %idle
100.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 325.00 0.00 1.27 8.00 2.17 7.18 0.00 7.18 1.17 38.10
avg-cpu: %user %nice %system %iowait %steal %idle
99.00 0.00 1.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 309.00 0.00 1.21 8.00 2.28 7.87 0.00 7.87 1.08 33.40
......
[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=1m --size=1G --runtime=60 --ramp_time=20 --ioengine=sync --numjobs=4 --filename=/dev/sdb --direct=1 --group_reporting --sync=1
randwrite: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=sync, iodepth=1
...
fio-3.1
Starting 4 processes
Jobs: 3 (f=3): [w(3),_(1)][58.2%][r=0KiB/s,w=4096KiB/s][r=0,w=4 IOPS][eta 00m:59s]
randwrite: (groupid=0, jobs=4): err= 0: pid=8396: Thu Mar 5 19:32:23 2020
write: IOPS=4, BW=4407KiB/s (4513kB/s)(261MiB/60647msec)
clat (msec): min=406, max=1552, avg=928.17, stdev=188.99
lat (msec): min=406, max=1552, avg=928.21, stdev=188.99
......
......
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 5.00 0.00 5.00 2048.00 3.77 753.40 0.00 753.40 2.00 1.00
avg-cpu: %user %nice %system %iowait %steal %idle
99.01 0.00 0.99 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 0.00 3.96 0.00 3.96 2048.00 3.40 860.50 0.00 860.50 2.00 0.79
…
总结
可以看到当 IO size 较小时, 硬盘即使压力不大( sdb 为 ssd ) %util 也达到了 30% , 后来当 IO size 为 1M 时磁盘实际负载并不会比之前低, 但是 %util 却很低, 这与要是由于不同 size 的 IO 造成内核 IO queue 里面停留时间不同造成的, 和硬盘本身的负载并没有直接的关系