await才是核心i/o延迟指标，avgqu-sz与await必须联合解读：前者反映队列积压程度，后者体现单请求平均耗时；二者同步上升表明块层排队，而await远高于svctm则确认排队开销主导。
磁盘队列长度和系统平均响应时间不是两个孤立指标，而是同一压力在不同层级的体现：队列长度反映“积压了多少请求”，平均响应时间（await）反映“每个请求等了多久才完成”。二者必须交叉看，单看任一数值都容易误判。
核心关系：avgqu-sz 和 await 必须联合解读
avgqu-sz 是 iostat -x 输出中“平均 I/O 队列长度”，本质是采样周期内块层中等待+处理中的请求数均值；await 是该周期内每个请求从入队到完成的平均耗时（毫秒）。它们的关系近似满足：
- await ≈ svctm + (avgqu-sz × svctm) —— 当请求串行化时成立；更准确地说，await 显著大于 svctm（比如差值 >5ms），就说明 avgqu-sz 真正代表排队开销，而非设备处理慢
- avgqu-sz 持续 ≥ 1 且与 await 同步上升 → 排队正在发生，不是瞬时抖动
- avgqu-sz 很低（如 0.2）但 await 很高（如 80ms）→ 问题不在队列，而在设备响应本身（驱动挂起、链路重传、硬件错误）
区分设备类型，设定合理判断阈值
机械盘、SATA SSD、NVMe 的物理队列能力差异巨大，不能用同一套数字下结论：
- HDD：avgqu-sz 长期 ≥ 4 且 await > 10ms → 大概率寻道/旋转延迟导致排队
- SATA SSD：硬件 queue_depth 多为 32，avgqu-sz > 25 并伴随 await > 2ms → 队列开始饱和
- NVMe：单队列深度常达 64k，avgqu-sz = 80 完全正常；关键看 await 是否稳定
查真实队列上限，别被 avgqu-sz 迷惑
avgqu-sz 是结果，不是配置。要判断是否“真堵”，得知道设备最大能接多少请求：
- NVMe 设备（如 nvme0n1）：cat /sys/block/nvme0n1/device/queue_depth
- SATA/SAS 设备（如 sda）：cat /sys/block/sda/device/queue_depth
- 老式单队列设备（如部分 USB 盘）：cat /sys/block/sda/queue/nr_requests
- 若读取报 “No such file”，说明队列深度由固件或内核硬编码，不可调
向下验证瓶颈到底在哪一层
当 avgqu-sz 和 await 都异常，但上层工具（iotop、pidstat）找不到明显大户时，需下沉检查：
- 用 blktrace -d /dev/nvme0n1 -o - | blkparse -i - 看 Q→G（进队列到取请求）延迟：若显著拉长，问题在块层调度或锁争用
- 看 I→C（下发到完成）耗时：若超长，直奔硬件、驱动或 PCIe 链路（配合 dmesg | grep -i "nvme\|error"）
- 查 /proc/diskstats 第 9 列（aveq）和第 11 列（await_ms 累加值）：差值比对可避开 iostat 采样平滑，更接近真实堆积趋势
