await才是核心i/o延迟指标：hdd>10ms或ssd/nvme>1ms需介入，持续>50ms确认严重瓶颈；r_await高查读密集操作，w_await高但w/s低说明小写阻塞队列；avgqu-sz>1且上升表明块层排队；iotop -op易漏短时高频小i/o、mmap回写及管道间接落盘；await高而进程级工具无异常时，应查/proc/diskstats、调度器配置及dmesg错误。
Linux 没有“系统平均响应时间”这个全局指标，await 才是你要盯死的核心延迟值——它直接反映磁盘 I/O 请求从发出到完成的平均耗时（单位毫秒），比任何上层应用日志或主观感知都准。
iostat -x 1 看什么字段才管用
别扫一眼 %util 就下结论。真正决定用户是否卡住的是 await、r_await 和 w_await：
-
await > 10ms（HDD）或> 1ms（SSD/NVMe）就要立刻介入；持续 >50ms 基本确认存在严重瓶颈 -
r_await远高于w_await？重点查读密集型操作：数据库索引扫描、日志轮转、备份脚本全量读取 -
w_await爆高但w/s很低？很可能是少量随机小写（如 4KB）打满了设备队列深度，不是吞吐问题而是调度/队列问题 -
avgqu-sz > 1且持续上升 +await同步涨？说明请求在内核块层排队，不是磁盘慢，是压过头或调度器不匹配
iotop -oP 为什么总漏掉真凶
iotop -oP 只显示“正在执行 I/O”的进程，但它对三类行为完全隐身：
- 短时高频小 I/O：比如每秒几千次
write(2)调用，iotop统计周期内可能只捕获到零星几帧 - 内存映射写入（
mmap+msync或脏页自动回写）：数据走 page cache → bdi flush，不经过进程级 I/O 路径 - 管道/套接字间接落盘：比如 nginx 日志通过
syslog-ng转发再写磁盘，iotop显示的是syslog-ng，不是源头
实操建议：先跑 iotop -oPa（-a 显示累计 I/O），再补一句 pidstat -d 1 3 对比；若两者都平，但 await 高，立刻查 /proc/vmstat 中的 pgpgout（脏页回写量）和 pgmajfault（大页缺页中断）。
查不到进程就去 /proc/diskstats 看底层排队
当 iotop 和 pidstat 都安静，但 await 居高不下，说明 I/O 堵在更底层——比如驱动、队列、硬件链路：
- 执行
cat /proc/diskstats，对比同一设备前后 5 秒的第 9 列（aveq，加权队列长度）和第 11 列（await的原始累加值），看是否真实堆积 - 检查
/sys/block/nvme0n1/queue/scheduler：NVMe 必须是none，若显示mq-deadline或bfq，说明调度器被错误启用，会强制串行化请求 - 运行
dmesg | grep -i "nvme\|ata\|error\|timeout"：链路重试、ACPI power state 异常、PCIe AER 错误都会导致延迟毛刺，这类问题iostat完全不体现
最常被忽略的一点：await 高 ≠ 磁盘坏了。它可能只是内核在等一个还没触发的 fsync，或某个进程卡在 D 状态等待不可中断的块 I/O 完成——这时候看 ps aux | grep " D " 比跑 smartctl 更快。
