iostat -x 1 的核心是联动分析 await、r_await、w_await 和 avgqu-sz：await >30ms 且 avgqu-sz >8（NVMe）或 >4（SSD）表明真实 I/O 瓶颈；高 await 低 %util 指向内核或文件系统问题，而非磁盘物理能力不足。
重点看 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）才好评估真实负载
