await 是最能反映业务实际感知的磁盘 I/O 延迟指标，排查时必须重点关注：HDD 超过 10ms、SSD/NVMe 超过 1ms 就需要及时介入，持续高于 50ms 基本可以判定存在严重性能瓶颈；结合 r_await 和 w_await 还能快速区分读密集与写密集问题；而 %util 在 SSD 场景下经常失真，不能作为核心判断依据。
iostat -x 1 的 await 是你必须持续关注的核心磁盘延迟指标
在 Linux 系统中，并没有一个统一的“系统平均响应时间”全局指标。对于业务请求来说，真正能感知到的磁盘 I/O 延迟，通常就体现在 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，把队列深度打满，本质不是吞吐不足，而是 I/O 调度或队列参数配置不合理- 不要过度依赖
%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 列（a veq，加权队列长度）和第 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 电源状态异常（例如
acpi PNP0A08:00: fail to set _PS0）可能导致 NVMe 控制器频繁软复位，从而引发毫秒级延迟抖动 - 驱动或固件缺陷也很常见：某些 Intel/OCP NVMe 盘会在特定负载下触发 timeout，这种情况下应优先升级固件，而不是直接更换硬盘
- 物理链路故障同样不能忽视：PCIe 插槽松动、主板供电不稳定、线缆接触不良，都会导致 I/O 重试和超时，而这些线索通常只能从
dmesg中看到
真正棘手的磁盘延迟问题，往往就藏在 dmesg 里的那几行关键报错中，而不是你反复跑第十次 fio 测试得到的基准结果。
