Linux iostat await 和 util 怎么看：区分磁盘延迟、队列堆积与设备忙碌

磁盘告警里最容易被误读的是 %util：看到它接近 100%，就直接下结论说“磁盘满了”。实际排查 Linux I/O 时，await、aqu-sz 和 %util 必须放在同一个采样窗口里看，才能分清请求是在排队、设备服务慢，还是并行设备的统计口径让利用率看起来很高。

先用 iostat -x -y 2 6 取得连续样本，再把 await、aqu-sz、%util 与读写方向放在一起判断；单看一列，尤其是 %util，不足以证明设备已经到达性能上限。

先把 iostat 的首次报告排除掉

iostat 默认会先输出一段从系统启动到当前时刻的累计统计。服务器刚经历过批处理或备份时，这一行可能和眼前的故障窗口完全不是一回事。排查现场先固定设备、间隔和样本数：

iostat -x -y 2 6

-x 展开设备级指标，-y 跳过第一份历史报告，2 6 表示每 2 秒采样一次，共输出 6 份报告。先观察第二到第六份是否稳定，再谈某个数字是不是异常。样本期间最好不要同时重启服务或手工制造大量 I/O，否则你看到的是操作本身的影响。

await 高，究竟高在排队还是高在服务时间

await 是 I/O 请求从发出到完成的平均时间，包含请求在队列里等待的时间，也包含设备真正处理请求的时间。它不是“磁盘转速”的别名，也不能直接当成某个固定硬件的健康阈值。

排查时至少把它和 aqu-sz、读写方向、吞吐一起看：

这里别急着把参数改成“更大的队列”。队列变长可能只是把等待藏起来，应用侧的请求延迟反而更难解释。先用 pidstat -d 2 6 或业务日志找出读写来源，再回到设备行核对。

%util 接近 100% 时，先确认设备是不是并行处理

%util 表示在统计时间里，设备有 I/O 请求处于活动状态的比例。对一次只能服务有限并发请求的设备，它接近 100% 往往值得警惕；但现代 SSD、NVMe 或 RAID 可以同时处理多个请求，此时设备持续忙碌不等于已经达到吞吐或 IOPS 极限。

更稳妥的判断是看趋势：%util 很高、await 持续上升、aqu-sz 同时堆积，且业务延迟同步变差，才更像设备或下游路径正在成为瓶颈。如果 %util 高但 await 平稳、队列接近零，先检查业务负载类型、设备并行度和采样窗口，不要直接扩容或替换磁盘。

用固定采样结果做一次反向验证

假设某次采样显示 await=18ms、aqu-sz=0.20、%util=98%。这个组合只能说明设备在窗口内几乎一直有请求，但队列并不长，不能单独证明“磁盘已经跑满”。如果下一轮业务高峰中 await 变成 80ms、aqu-sz 逐步增大，且读写吞吐接近不再增长，证据才开始指向排队和服务能力不足。

复测时保持三件事不变：同一个设备名、同一个采样间隔、同一个业务负载。若设备被 LVM、容器或虚拟化层包住，还要把上层设备和底层块设备放在同一时间段对照，避免只看其中一层。

常见问题：iostat 三列读数怎么避免误判

为什么第一次 iostat 输出总是和后面不同？

第一次报告可能覆盖系统启动以来的累计区间，历史负载会稀释或放大当前现象。使用 -y 跳过它，再用固定间隔采样。

await 高是不是一定要换磁盘？

不是。先确认请求是否排队、读写方向是否变化，以及高等待是否和业务延迟同步出现。样本太少或只发生在单一请求类型时，不能直接推导硬件结论。

%util 为什么高了但 aqu-sz 还是很低？

设备可能一直有请求但并没有形成长队列，或者设备具备并行处理能力。继续观察 await、吞吐和业务延迟，再判断是否接近真正上限。

把判断落到三列联读

日常值班可以把结论压缩成一句话：先用 await 看请求等了多久，再用 aqu-sz 看是否在排队，最后用 %util 判断设备是否持续有活跃请求；遇到 SSD、NVMe 或 RAID，再把并行处理能力和业务延迟补进证据链。这样得到的判断可复测，也比“util 100% 所以磁盘坏了”更接近真实现场。