关键看await与svctm差值、avgqu-sz堆积及%util虚高：await−svctm显著超阈值（SSD＞2ms/机械盘＞10ms）表明队列积压；avgqu-sz＞8（NVMe）或＞1（SATA SSD）且%util未达100%提示上层调度或锁争用问题。
直接用 iostat -x 观察高 IOPS 场景下的等待队列与服务时间，关键不是看单个数值高低，而是看它们之间的关系是否失衡。真实瓶颈往往藏在 await 和 svctm 的差值、avgqu-sz 的持续堆积，以及 %util 是否“虚高”里。
重点关注 await 与 svctm 的差值
在极高 IOPS 下，await（平均请求耗时）必然上升，但真正反映排队压力的是它和 svctm（平均服务时间）的差距：
-
await - svctm显著大于 1–2ms（SSD）或 5–10ms（机械盘），说明请求大量滞留在内核 block layer 队列中，而非设备本身慢 -
svctm本身已不可靠（内核 2.6.34+ 后基本弃用），但只要await远高于设备标称延迟（如 NVMe 常态应 - 若
await持续 > 20ms 且svctm也同步升高，需怀疑介质老化、RAID卡缓存失效或驱动异常
结合 avgqu-sz 判断队列深度是否溢出
avgqu-sz 是每秒平均挂起的 I/O 请求数，它是 await 背后的直接推手：
- 对单盘 NVMe，
avgqu-sz > 8就可能触发深度排队；SATA SSD 建议阈值为 - 若
avgqu-sz持续 > 1 且%util接近 100%，说明设备吞吐已达极限，IOPS 再高也无法被及时消化 - 若
avgqu-sz很高（如 > 10）但%util却只有 60%–80%，大概率是上层调度问题：IO 调度器（如 mq-deadline）未适配多队列设备，或文件系统 journal 锁争用严重
用 r_ios/w_ios + avgrq-sz 反推 IO 模式是否合理
高 IOPS 不等于高效 —— 小块随机 IO 容易把队列压爆，而大块顺序 IO 即使 IOPS 不高，吞吐也能拉满：
- 计算平均请求大小：
avgrq-sz × 512（单位字节）。若结果长期 - 对比
r_ios + w_ios（真实下发到设备的 IOPS）与设备标称值：NVMe 盘标称 500K IOPS，若实测仅 80K 但avgqu-sz已达 12，说明应用并发不足或存在串行化瓶颈（如单线程写日志） - 若
r_ios极高但rMB/s很低，基本可断定是大量 4K/8K 随机读写，此时优化方向是合并 IO、启用 write-back 缓存或调整应用逻辑
排除干扰：区分真瓶颈与假饱和
高 IOPS 下 %util ≈ 100% 很常见，但它不等于磁盘过载：
- 若
%util高 +await低 +rMB/s接近设备带宽（如 PCIe 4.0 x4 NVMe 达 3GB/s），属于健康满载，无需干预 - 若
%util高 +await高 +rMB/s却远低于理论值（如只跑出 200MB/s），说明设备被大量小 IO 占满，物理带宽未被有效利用 - 此时应配合
iotop -o或pidstat -d 1查具体进程，并用lsof + /proc/pid/io确认其 IO 模式（O_DIRECT？buffered？sync？）
