兔子蛋糕
磁盘负载指标%iowait,await,%util的正确理解
说明
%iowait, await, %util 是⽤来衡量硬盘负载的三个指标, 但是这⼏个指标通常容易被误解, 实际上, 这三个指标单纯的⾼, 并不⼀定能说明相应的磁盘有问题或者有瓶颈, ⽽是需要结合具体执⾏ IO 操作的程序的执⾏⽅式, 综合的来判断指标⾼的原因.
关于 await, %util 的计算⽅式可以参照:
总结
%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-relea
CentOS Linux relea 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: %ur %nice %system %iowait %steal %idle
肩肘倒立教学视频1.46 0.00 0.78 1
2.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: %ur %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 urs, 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 ud, 175296 buff/cache
KiB Swap: 1572860 total, 1572860 free, 0 ud. 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=/d ev/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/60004mc)
clat (uc): min=2917, max=48358, avg=11505.79, stdev=4808.19
lat (uc): min=2918, max=48359, avg=11506.34, stdev=4808.19
.....
iowait 达到了 99%
好看的英语......
avg-cpu: %ur %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: %ur %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
此时 CPU 利⽤率已经⾮常⾼
[root@centos-76-c1~]# top -n 1
top - 17:59:21 up 1:22, 3 urs, 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 ud, 175336 buff/cache
KiB Swap: 1572860 total, 1572860 free, 0 ud. 697288 avail Mem
这是可以看到 %iowait 直接变成了 0.00
......
avg-cpu: %ur %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: %ur %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> --iodep th_batch_submit=<iodepth> --iodepth_low=<iodepth> --numjobs=1 --filename=/dev/sdb --direct=1 --group_reporting
测试结果
iodepth IOPS BW avgqu-sz await 190363KiB/s0.20 3.03
43371349KiB/s 2.17 6.51
1611684676KiB/s10.007.50
6418287317KiB/s47.9718.33
25618517424KiB/s252.03300 ~ 500
102417236963KiB/s270.84300 ~ 600
总结
随着并发度越来越⾼, 达到了本机 IO 能承受的 IO 的上限, ⼤量 IO 在存储集群⾥⾯排队, 可以看到 aw
ait 随着 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 --iod epth_batch_submit=1 --iodepth_low=1 --numjobs=1 --filename=/dev/sdb --direct=1 --group_reporting
测试结果
block_size IOPS BW avgrq-sz avgqu-sz await 4KiB90364KiB/s8.000.25 2.93
16KiB691120KiB/s32.000.649.75
64KiB301948KiB/s128.000.8430.11
256KiB113004KiB/s512.000.9389.90
1MiB44168KiB/s2048.00 1.14227.00
4MiB14531KiB/s2048.00 - 2560.00 3.46902.75
16MiB05206KiB/s2048.00 - 2560.0012.502223.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=/de v/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
40集团军Starting 4 process
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/60004mc)
......
......
Davg-cpu: %ur %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: %ur %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=/de v/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 process
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/60647mc)
clat (mc): min=406, max=1552, avg=928.17, stdev=188.99
lat (mc): 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: %ur %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 ⾥⾯停留时间不同造成的, 和硬盘本⾝的负载并没有直接的关系
