iostat -x 1 是分析极高并发iops下等待队列与服务时间的唯一有效起点，需结合avgqu-sz与await组合判断：avgqu-sz≥8（sata ssd）或≥64（nvme）且await>2ms表明队列堆积；avgqu-sz≈1但await>5ms则指向物理层问题；%util≈100%需结合r/s、await、rmb/s甄别虚高或真饱和。
直接用 iostat -x 1 每秒刷新，是分析极高并发 IOPS 下等待队列与服务时间的起点。关键不是看单个数值高低，而是拆解请求生命周期：它在哪排队、等多久、是否真被设备处理了。
盯住 avgqu-sz 和 await 的组合信号
avgqu-sz 是平均队列长度，代表内核提交后尚未完成的请求数；await 是请求从发出到返回的总耗时（排队 + 服务）。二者必须一起看：
- avgqu-sz ≥ 8（SATA SSD）或 ≥ 64（NVMe）且 await > 2ms → 队列持续堆积，设备消费能力跟不上提交节奏
- avgqu-sz ≈ 1 但 await > 5ms → 几乎不排队却很慢，问题大概率在物理层（NAND坏块、RAID卡缓存失效、控制器降频）
- avgqu-sz > 100 但 await 很低（如 iotop -o 查峰值行为
用 r_await 和 w_await 分离读写瓶颈
混合负载下，单看 await 容易误判。读写延迟差异暴露路径级问题：
- r_await 显著高于 w_await（如 15ms vs 2ms）→ 读路径受阻，可能是 page cache 未命中、ext4 barrier 等待或 XFS log stall
- w_await 显著偏高（如 >20ms）且 wkB/s 不高 → 同步写瓶颈，常见于 fsync() 调用密集、journal 刷盘锁争用或 write-back 缓存被禁用
- 两者都高但差值小 → 再比对 svctm（仅作参考）：若 svctm ≈ await，说明无排队，纯服务慢；若 await ≫ svctm，排队主导延迟
识别 %util “虚高”与真实饱和
%util 接近 100% 在 NVMe/SSD 高并发场景非常普遍，不能直接等同于磁盘过载：
- %util = 98% + r_ios = 120K + await = 0.4ms → 健康满载，设备高效运转
- %util = 99% + r_ios = 15K + await = 35ms → 异常假饱和：IOPS 极低却占满，可能因 LVM thin pool 元数据锁、ext4 barrier 或驱动未启用多队列
- %util 高 + rMB/s 远低于理论带宽（如 PCIe 4.0 x4 NVMe 标称 3GB/s，实测仅 200MB/s）→ 小块随机 IO 占满队列，物理带宽未被有效利用
验证队列深度是否匹配硬件能力
Linux 实际生效的队列深度由应用、blk-mq 层、硬件三者最小值决定：
- 查硬件队列容量：cat /sys/block/nvme0n1/device/queue_depth（NVMe）或 cat /sys/block/sda/device/queue_depth（SATA）
- 查逻辑队列深度：cat /sys/block/nvme0n1/queue/depth
- 若 avgqu-sz 长期接近该值（如 queue_depth=256，avgqu-sz≈240）→ 队列深度已成硬瓶颈
- OLTP 类负载建议设为 64–256；顺序吞吐类保持 32–64 即可，盲目调大可能引发设备内部拥塞
