iostat -dx 1 是唯一能直接给出磁盘读写延迟毫秒值的命令，关键字段为：r_await（读请求平均耗时）、w_await（写请求平均耗时）、await（混合平均延迟）、aqu-sz（平均队列长度＞1表明排队导致延迟）；svctm已废弃，%util在nvme上失效。
iostat -dx 1 是唯一能直接告诉你“磁盘读写延迟多少毫秒”的命令，其他工具要么间接、要么需要组合推断。
iostat -dx 1 输出里哪些字段真代表读写延迟
不加 -x 的 iostat 根本看不到延迟——它只显示吞吐量和 IOPS。加 -x 后才暴露真实耗时：
-
r_await：每个读请求从发出到完成的平均耗时（毫秒），含排队 + 设备服务时间 -
w_await：每个写请求的平均耗时（毫秒），同上 -
await：读写混合后的综合平均延迟，但掩盖了读/写差异 -
aqu-sz：平均队列长度，>1 表示请求已在排队，延迟主因不是设备慢，而是并发压太狠
注意：svctm 已被内核废弃，数值不可信；%util 在 NVMe 上基本失效，别再拿它当瓶颈判断依据。
为什么不能只看 iostat，还得配合 ioping
iostat 给的是系统视角的“平均”延迟，但掩盖了抖动和长尾。比如 r_await 显示 0.4ms，实际 p99.9 可能飙到 12ms——这种问题 iostat 完全发现不了。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 用
ioping -C -c 10 /dev/nvme0n1测裸设备同步延迟，avg> 0.2ms 就得查硬件或驱动 -
ioping绕过文件系统和 page cache，测的是块设备层真实响应，-C强制落盘，排除缓存干扰 - HDD 延迟通常 5–15ms，SATA SSD 应
iotop 能帮你确认延迟是不是由某个进程引发的
iotop 不报延迟数值，但它能把 iostat 看到的高 w_await 和具体进程对上号——这是定位根因的关键一环。
- 必须用
sudo iotop -o：不加sudo看不到系统进程；不加-o会被大量休眠进程刷屏 - 盯
DISK WRITE列（KB/s），不是IO%：后者是相对占比，mysqld占 30% IO% 但写 8MB/s，比占 90% IO% 却只写 100KB/s 的日志进程更值得优先查 - 查到高写进程后，立刻
lsof -p PID看它在操作哪个文件，再cat /proc/PID/io对比write_bytes和wchar：差太多说明卡在 page cache，不是磁盘本身慢
fio 是唯一能看清延迟分布的工具
当你发现 r_await 波动剧烈，或业务偶发超时却找不到规律，就得用 fio 抽取百分位延迟。
- 配置必须含
direct=1（绕缓存）、iodepth=32（模拟真实并发）、runtime=60（足够采样） - 关键输出在
clat_ns（complete latency）：p99.9> 1ms 对 NVMe 就是严重问题，p99> 10ms 对 HDD 已属异常 - 别用
dd测延迟：dd if=/dev/zero of=test bs=1M oflag=direct只反映顺序大块吞吐，完全不模拟随机小 IO 场景
真正难的不是跑出数字，而是区分「慢磁盘」和「慢应用」：如果 r_await 高但 svctm 极低（比如 0.02ms），说明卡在队列里——可能是上层调度器、文件系统锁或应用自身逻辑阻塞，不是硬件问题。
