iostat -x 中反映队列深度的核心字段是 avgqu-sz，表示平均排队请求数；结合 await、r_await、w_await 和 %util 可判断是否因队列积压导致高延迟，而非设备本身响应慢。
iostat -x 本身不直接显示“队列等待深度”这个指标，但可通过 avgqu-sz（平均队列长度）和 await、r_await、w_await 等指标综合判断块设备在高 IOPS 场景下的队列积压情况。真正反映“等待深度”的核心字段是 avgqu-sz —— 它表示设备驱动层（或内核 I/O 调度器）中平均有多少个 I/O 请求处于排队等待状态（含正在服务的请求）。
理解 avgqu-sz：队列深度的直接体现
该值不是并发请求数上限，而是采样周期内的平均值。例如：
- avgqu-sz = 1.2：平均约有 1~2 个请求在队列中（含正在处理的）；
- avgqu-sz ≥ 8（尤其对 NVMe 或高速 SSD）：提示队列持续饱和，可能成为瓶颈；
- avgqu-sz 远高于设备理论并行能力（如 SATA SSD 通常 ≤ 32，NVMe 可达 64/128+）：说明上层 I/O 压力已超出设备处理节奏。
结合 await 和 r/w_await 判断等待是否由队列引起
仅看 avgqu-sz 不够——需排除存储响应慢（如磁盘寻道、SSD GC）导致的等待。关键看：
- await 显著 > r_await 和 w_await 的差值很小：说明读写延迟相近，瓶颈更可能在队列或共享路径（如 HBA、RAID 卡）；
- r_await ≫ w_await（或反之）：可能是特定类型 I/O（如小随机读）引发调度/缓存压力；
- await 持续 > 10ms（SSD）或 > 50ms（HDD）且 avgqu-sz 高：大概率存在队列积压，而非单纯设备慢。
高 IOPS 下正确采集与解读 iostat -x 数据
避免瞬时抖动干扰，建议：
- 用 iostat -x 1 5（每秒刷新，共 5 次），忽略首行（初始平均值不可靠），重点看后 4 行稳定值；
- 关注 %util：若接近 100% 且 avgqu-sz 持续高位，说明设备已满负荷；但注意：NVMe 多队列下 %util 意义减弱，应更依赖 avgqu-sz + IOPS + await；
- 对比 rrqm/s 和 wrqm/s：若归并率高（如 >30%），说明 I/O 合并有效，队列压力部分被缓解；归并率低而 avgqu-sz 高，则请求过于离散，加剧队列竞争。
补充验证：用 iotop 或 /proc/diskstats 交叉确认
iostat 提供聚合视图，但无法定位进程级队列行为：
- iotop -o -a：查看哪些进程产生大量 I/O，是否单进程突发导致队列尖峰；
- 查 /proc/diskstats 中对应设备的第 11 列（avg_queue_size，内核 5.0+ 支持）或通过 `cat /sys/block/*/stat` 解析字段，可获取更底层队列统计；
- 对 NVMe 设备，还可运行 nvme get-log 查看 SQ/CQ 深度使用情况，比 avgqu-sz 更贴近硬件队列实际。
