await字段代表磁盘I/O操作平均响应延迟值，单位毫秒，包含队列等待与设备服务时间，是用户感知卡顿的直接依据；svctm已弃用，%util在NVMe下失效；HDD>10ms或SSD/NVMe>1ms需排查，持续>50ms确认严重瓶颈。
直接看 iostat -x 1 的 await 字段，它就是你要的“磁盘 I/O 操作平均响应延迟值”，单位毫秒（ms），不是估算，是内核实测统计。
iostat -x 输出里哪个字段代表真实延迟
await 是唯一需要盯死的指标：它包含请求在队列中等待时间 + 设备实际服务时间，是用户感知卡顿的最直接依据。别信 svctm——它早在 Linux 2.6 内核就被标记为“已弃用”，数值常失真甚至为 0；%util 只对传统单队列设备有意义，NVMe 下基本失效。
-
await > 10ms（HDD）或> 1ms（SSD/NVMe）就要介入排查 -
await持续 > 50ms 基本确认存在严重瓶颈，不是“可能慢”，是“已经卡住” - 同一设备上
r_await和w_await差异大，说明读/写路径各自有问题，比如r_await高但w_await正常，优先查数据库索引扫描或日志归档脚本
为什么 iotop 看不到 await 对应的进程
iotop -oP 显示的是“正在执行 I/O”的进程快照，但它对三类高频、间接、内核级 I/O 完全隐身：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 短时高频小 I/O：比如每秒几千次
write(2)，iotop默认 1 秒采样周期根本捕不到完整行为 - 内存映射写入（
mmap+ 脏页回写）：数据走 page cache →pdflush/writeback线程，不经过进程 I/O 路径 - 管道/套接字间接落盘：如 nginx 日志经
syslog-ng转发再写磁盘，iotop只显示syslog-ng，不暴露源头
此时若 await 高但 iotop 平静，别继续刷 iotop，立刻切到 pidstat -d 1 3 对比累计 I/O，再查 /proc/vmstat 中的 pgpgout（脏页回写量）和 pgmajfault（大页缺页中断）。
await 高但找不到进程？去 /proc/diskstats 看底层排队
当 iotop 和 pidstat 都安静，await 却持续高位，问题一定在块层以下：
- 执行
cat /proc/diskstats，定位目标设备行（如nvme0n1），重点看第 9 列（aveq，加权队列长度）和第 11 列（await的原始累加值），对比前后 5 秒变化——若两者同步上涨，说明请求真正在内核块层堆积 - 检查调度器：
cat /sys/block/nvme0n1/queue/scheduler，NVMe 必须是none；若显示mq-deadline或bfq，说明被错误启用，会强制串行化请求，人为拉高await - 运行
dmesg | grep -i "nvme\|ata\|error\|timeout"：PCIe 链路重试、ACPI 电源状态异常、AER 错误都会导致毫秒级毛刺，iostat完全不体现，但await会跳变
真正容易被忽略的点：高 await 不等于磁盘坏了，它可能只是某个应用还没触发 fsync，或者内核在等一个未完成的 journal 提交——这时候看 /proc/diskstats 的队列深度比看 SMART 更管用。
