await是iostat -x输出中第11列的平均i/o等待时间（毫秒），含排队与处理耗时；hdd>10ms、sata ssd>2ms、nvme>0.5ms需警惕，持续>50ms表明严重延迟，须结合r_await/w_await、%util及/proc/diskstats等深入定位瓶颈根源。
iostat -x 输出里的 await 字段就是你要的平均等待时间
直接运行 iostat -xmt 2，每行设备数据里第 11 列的 await 就是该设备所有 I/O 请求从发出到完成的平均耗时（单位毫秒），它包含排队时间和设备处理时间。这不是估算值，是内核 block layer 实时统计的加权平均。
-
await> 10ms（HDD）、> 2ms（SATA SSD）、> 0.5ms（NVMe）就该警惕；持续 > 50ms 基本确认存在严重延迟 - 别只看总
await，必须同时盯住r_await和w_await：如果r_await高但w_await正常，问题大概率出在读路径（比如数据库全表扫描、日志轮转） -
await高但%util很低（比如
为什么 top 或 vmstat 里的 %wa 不能代替 await
%wa（或 %iowait）只是 CPU 在空闲时等待 I/O 完成的时间占比，它不告诉你“等了多久”，只告诉你“CPU 有段时间在等”。一个进程反复发小请求、每次等 1ms，%wa 可能很低；另一个进程发一次大请求、卡住 500ms，%wa 却可能爆到 80%——但两者对用户体验的影响完全不同。
- 用
top看到%wa高，只是触发排查的起点，不是结论 -
vmstat 1中的b（阻塞进程数）持续 > 0，且与wa同步升高，才算是较可靠的 I/O 阻塞信号 - 单靠
%wa无法区分是磁盘慢、文件系统锁、还是应用层频繁fsync导致的延迟毛刺
await 高但找不到高 IO 进程？去 /proc/diskstats 和调度器查
当 iostat -x 显示 await 持续偏高，但 iotop -oPa 和 pidstat -d 1 都看不到明显罪魁，说明 I/O 堵在了进程之外的路径：比如脏页回写、mmap 写入、或块设备队列本身。
- 执行
cat /proc/diskstats，对比同一设备前后 5 秒的第 9 列（aveq，加权队列长度）是否显著增长——真堆积，这里会暴露 - 检查调度器：
cat /sys/block/nvme0n1/queue/scheduler，NVMe 设备必须是none，若显示mq-deadline或bfq，说明被错误启用，会人为引入串行化延迟 - 运行
dmesg | grep -i "nvme\|ata\|error\|timeout"，PCIe 链路重试、ACPI power state 异常这类底层错误，iostat完全不体现，但会导致await毛刺式飙升
别信 iotop 的 IO% 数值，它和 await 不是一回事
iotop 显示的 IO% 是进程级 I/O 时间占总调度时间的比例，和 await 完全不同源。一个进程 IO% 95% 但 await 只有 1ms，说明它发请求快、设备响应也快；反过来 IO% 仅 5% 但 await 达 200ms，意味着它虽然不常发请求，但每次都在深水区卡住。
- 验证进程状态：
ps -o pid,comm,state -p <pid></pid>，看到D（不可中断睡眠）才说明真在等 I/O - 用
strace -p <pid> -e trace=read,write -T</pid>抓单次系统调用耗时，如果<read></read>或<write></write>后面显示（毫秒级），就和await对得上；如果都是微秒级，那高await就不在这个进程身上 - 数据库类进程优先查慢查询日志和
EXPLAIN，而不是盯着await换硬盘——90% 的 case 是 SQL 问题引发的间接 I/O 压力
真正容易被忽略的是：await 高但 %util 低时，换更快的盘毫无意义；问题往往在文件系统锁或内核 block layer 队列，得往 /proc/vmstat 和调度器配置里挖。
