iostat -x 1 的核心是联动分析 await、r_await、w_await 和 avgqu-sz：await >30ms 且 avgqu-sz >8（nvme）或 >4（ssd）表明真实 i/o 瓶颈；高 await 低 %util 指向内核或文件系统问题，而非磁盘物理能力不足。

直接用 `iostat -x 1` 就能实时看磁盘 IO 响应等待时间，关键不是单看一个数，而是盯住 `await`、`r_await`、`w_await` 和 `avgqu-sz` 这几个字段的组合。

重点看 await、r_await、w_await

await 是平均每次 I/O 请求从发出到完成的总耗时（毫秒），包含排队时间和设备处理时间。
r_await 和 w_await 分别是读、写请求的平均等待时间，能帮你判断是读拖慢还是写拖慢。

参考阈值（持续超过即需关注）：
• 机械硬盘：> 15 ms
• SATA SSD：> 5 ms
• NVMe SSD：> 1 ms
• 若稳定 > 30 ms，基本确认存在排队或响应异常。

结合 avgqu-sz 判断排队是否真实

avgqu-sz 是平均 I/O 队列长度。它和 await 必须一起看：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• avgqu-sz > 1 且 await 同步升高 → 请求发得太快，底层处理不过来（比如应用并发过高、小块 IO 过多）
• avgqu-sz ≈ 0.2～0.5 但 await 却很高 → 不是队列堵，可能是单次大 IO、坏块重试、链路不稳定，或文件系统锁（如 XFS log stall、ext4 journal 竞争）
• avgqu-sz > 8（NVMe）或 > 4（SATA SSD）→ 上层下发严重超载，调度器或内核 block layer 已成瓶颈

避免被 %util 误导

%util 只表示设备忙时占比，对现代 SSD/NVMe 参考价值很低：

• 高 await + 低 %util（比如 20%）→ 问题不在磁盘本身，大概率在内核队列或文件系统层（换更快的盘没用）
• 高 await + 高 %util + 低吞吐（rMB/s + wMB/s 远低于理论带宽）→ 才可能是磁盘物理瓶颈（如 HDD 随机写、SSD 老化、RAID 缓存关闭）
• %util 接近 100% 但 await 正常、吞吐逼近上限 → 属于健康满载，不用干预

推荐命令与观察技巧

执行：iostat -xmt 2（每 2 秒刷新，带时间戳、MB 单位、扩展统计）

• 首次输出是系统启动以来的平均值，忽略；从第二次开始才是实时瞬时值
• 加 -d 参数隐藏 CPU 行，聚焦磁盘（默认混在一起容易看错）
• 若怀疑某块盘，可用 -p sda 或 -p nvme0n1 单独监控
• LVM 或容器环境里看到 dm-0、docker-8:1-xxx 等设备名，要对应到物理盘（如 sda）才好评估真实负载