磁盘负载指标%iowait-await-%util的正确理解.docVIP

磁盘负载指标%iowait,await,%util的正确理解 说明 %iowait, await, %util 是?来衡量硬盘负载的三个指标, 但是这?个指标通常容易被误解, 实际上, 这三个指标单纯的?, 并不?定能说明相应的磁盘有问题或者有瓶颈, ?是需要结合具体执? IO 操作的程序的执??式, 综合的来判断指标?的原因. 关于 await, %util 的计算?式可以参照: 总结 %iowait: 最容被误解的参数, 实际上这是?个?常宏观的系统指标, 其表? CPU空闲 并且 有未完成的IO 这种状态在?个采样周期?的占?, ?般来说当?个进程进?同步的 IO 操作时, 进程将会被挂起, CPU 将会空闲, 等待 IO 完成, 这时候如果没有其它进程占? CPU ft时的状态将会被计? iowait 的统计时间以内. 但是 CPU 空闲也只是当前进程空闲, 空闲出来的 CPU 是可以进?其它操作的, 如果ft时 %iowait 较?, 只能说明在等待 IO 完成的时间?系统没有其它进程来占? CPU 了, ? IO 未完成, 有可能只是单纯的 IO size ?较?, 完成需要较长时间, 并不 ?定是 IO 有问题. ?且如果等待 IO 完成时系统有其它繁忙的进程占?了 CPU, 那么?论ft时 IO 完成时间多长(即使是IO完全卡死), %iowait 也会?常的低, 因为ft时CPU不空闲了, 因为 %iowait 只是反映 CPU空闲 并且 有未完成的IO 这种状态时间的占?, 两个条件缺少?个都不会计?iowait 的时间. await 每个I/O的平均耗时, 包括在内核 IO 队列内的时间和在存储设备上执?ft 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 ??的时间, 所以ft时即使磁盘压?较?, 但是 IO queue 中并没有排队的 IO 那么 %util 也不会?(例如每次 IO size 都?较?), 或者有些程序进?顺序 IO, 完成?个再发下?个, 并且 IO size 并不?, ft时即使磁盘压?较? %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