iostat -dx 1是唯一能实时计算毫秒级磁盘I/O延迟的命令，它直接解析/proc/diskstats第11列（await累加值）与第4/8列（读写完成次数），输出r_await、w_await、await等关键字段，HDD超10ms、SATA SSD超1ms、NVMe超0.1ms即需排查。
直接看 iostat -dx 1，这是唯一能实时给出毫秒级磁盘 I/O 等待时间与响应延迟的命令。它从内核 /proc/diskstats 中第 11 列（await 累加值）和第 4/8 列（读写完成次数）动态计算出 r_await、w_await 和 await，单位统一为毫秒，不依赖缓存、不绕过块层，也不需要手动换算。
盯住三个关键延迟字段
r_await 和 w_await 分开反映读、写路径的平均耗时，await 是二者加权平均。它们不是“理论值”，而是真实请求从发出到完成所经历的全部时间，含队列等待 + 设备服务时间：
- HDD 超 10 ms、SATA SSD 超 1 ms、NVMe 超 0.1 ms 就该介入排查
- 若
w_await高但w/s很低，说明少量小写（如 4KB）已打满队列深度，不是吞吐问题，是调度或并发控制失当 -
r_await显著高于w_await，优先查数据库全表扫描、日志轮转、备份脚本等读密集行为
别被 %util 和 %wa 带偏方向
%util 在 NVMe 上基本失效，长期 99% 不代表卡顿；%wa（即 top 或 vmstat 中的 iowait）只表示 CPU 空闲时在等 I/O，并不等于磁盘慢——它可能源于内存不足触发 swap、文件系统锁争用，甚至 PCIe 链路重试。真正要判断瓶颈在哪，得结合：
-
avgqu-sz：持续 >1 表示请求已在块层排队；>5 且伴随 await 同步上升，大概率是上层并发失控或调度器错配 -
dmesg | grep -i "nvme\|ata\|error"：硬件链路异常（如 AER 错误、ACPI 电源状态切换）会导致毛刺型高延迟，iostat 完全不体现 -
cat /proc/diskstats对比前后几秒第 9 列（aveq）和第 11 列（await_sum），确认是否真实堆积
补充验证：用 ioping 和 fio 看不同维度
iostat 给你的是“当前负载下的平均延迟”，但掩盖了长尾。需要进一步验证时：
-
ioping -C -c 10 /dev/nvme0n1：强制同步写，测裸设备毫秒级往返延迟，排除文件系统与 page cache 干扰。NVMe 应稳定在 0.1–0.2 ms，超 0.5 ms 就需警惕 -
fio模拟业务 I/O 模式（如 randwrite + iodepth=32），重点看clat_ns中的 p99.9 值——如果 await=0.4ms 但 p99.9=80ms，说明偶发卡顿严重，这时刷 iostat 没用，得切 blktrace 或查 journal stall
进程级工具容易漏掉的三类真凶
iotop 和 pidstat 只捕获“正在发起系统调用”的 I/O，对以下情况完全隐身：
- 短时高频小 I/O（如每秒数千次 write(2)），统计周期内可能只采样到零星几次
- mmap + msync 或脏页自动回写（bdi flush），走 page cache 路径，不经过进程上下文
- 管道/套接字间接落盘（如 nginx → syslog-ng → disk），源头进程在 iotop 里 IO% 极低
遇到 await 高但进程级无异常，先跑 pidstat -d 1 3 对比累计 I/O，再查 /proc/vmstat 中 pgpgout（脏页回写量）和 pgmajfault（大页缺页中断）是否突增。
