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

磁盘负载指标%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 :2 1:58 EST 2020 x86_ 64 x86_ 64 x86_ 64 GNU/ inux [root@centos-76-c1~]# cat / etc/redhat-release entOS Linux release 7.6.1810 ( ore) [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 PU) avg-cpu: %user %nice %system %iowait %steal %idle 1.46 0.00 0.78 12.33 0.0