await是业务感知的磁盘i/o延迟真实反映，必须盯死：hdd>10ms、ssd/nvme>1ms需介入，持续>50ms确认严重瓶颈；r_await/w_await可区分读写密集型问题；%util在ssd场景下失真，不可依赖。
iostat -x 1 的 await 是你要盯死的唯一核心指标
Linux 没有“系统平均响应时间”这个全局值，await 就是业务请求感知到的磁盘 I/O 延迟真实反映。它包含排队时间 + 设备服务时间，单位毫秒，直接决定用户是否卡顿。
运行 iostat -x 1 后，只看三列：await、r_await、w_await：
-
await > 10ms（HDD）或> 1ms（SSD/NVMe）必须介入；持续 >50ms 基本确认严重瓶颈 -
r_await显著高于w_await？查数据库全表扫描、日志轮转、备份脚本等读密集操作 -
w_await高但w/s很低？典型小写阻塞：比如每秒几十次 4KB write，打满队列深度，不是吞吐问题，是调度/队列配置错 - 别信
%util：SSD 场景下它常低于 30% 却await已破 5ms，因为 %util 只统计“忙”的时间片，不反映延迟毛刺
iotop 和 pidstat 都可能漏掉真凶，得补上 /proc/diskstats 和 vmstat
iotop -oP 只捕获“正在做 I/O”的进程帧，对三类行为完全隐身：
- 短时高频小 I/O：比如应用每秒调用几千次
write(2)，iotop统计周期内只抓到零星几帧 - 内存映射写入（
mmap+msync或脏页自动回写）：走 page cache → bdi flush 路径，不经过进程级 I/O 系统调用 - 管道/套接字间接落盘：如 nginx 日志经
syslog-ng转发再写磁盘，iotop显示的是syslog-ng，不是源头
这时要立刻转向底层验证：
- 执行
cat /proc/diskstats，对比同一设备前后 5 秒的第 9 列（aveq，加权队列长度）和第 11 列（await原始累加值），看是否真实堆积 - 跑
vmstat -d 1或pidstat -d 1 3，看pgpgout（脏页写出量）是否突增 —— 若await高但进程 I/O 平静，大概率是内核在集中刷脏页 - 检查
/proc/vmstat中pgmajfault：透明大页（THP）触发的直接回收会拖慢 I/O 路径，尤其在高写入场景
NVMe 必须用 none 调度器，SATA SSD 别用 cfq
错误的 I/O 调度器会人为制造延迟，尤其在 NVMe 上：
- 运行
cat /sys/block/nvme0n1/queue/scheduler，输出必须是none；若显示mq-deadline或bfq，说明调度器被错误启用，会强制串行化请求，把 NVMe 的并行能力锁死 - SATA SSD 推荐
deadline或mq-deadline，cfq（已废弃）在 SSD 上反而增加开销 - 确认内核是否识别为 SSD：
cat /sys/block/sda/queue/rotational应返回0；若为1，即使物理是 SSD，内核也会按 HDD 处理，影响调度策略 - 队列深度（
nr_requests）也要匹配硬件：NVMe 默认足够大，但某些老驱动需手动调大/sys/block/nvme0n1/queue/nr_requests
延迟毛刺藏在 dmesg 里，iostat 完全不体现
await 高 ≠ 磁盘坏了，更可能是链路层异常，这类问题 iostat 和 fio 都测不出来：
- 运行
dmesg | grep -i "nvme\|ata\|error\|timeout"，重点找：nvme 0000:01:00.0: controller is down、ataX.00: failed command: READ FPDMA QUEUED、PCIe AER: Correctable error detected - ACPI power state 异常（如
acpi PNP0A08:00: fail to set _PS0）会导致 NVMe 控制器反复软复位，产生毫秒级毛刺 - 驱动固件 bug：某些 Intel/OCP NVMe 卡在特定负载下触发 timeout，需升级固件而非换盘
- 物理链路问题：PCIe 插槽松动、主板供电不稳、线缆接触不良，都会导致重试和超时，
dmesg是唯一出口
真正难搞的延迟问题，往往卡在 dmesg 里那几行报错，而不是你跑的第十遍 fio 测试结果上。
