Linux怎么查看具体的IO平均响应延迟

await可以说是判断I/O延迟最关键的指标之一，它表示单个I/O请求从发起到完成的平均耗时，单位是毫秒，里面既包含排队时间，也包含真正的服务时间。一般来说，HDD一旦超过10ms、NVMe超过1ms，就该开始介入排查了；如果持续高于50ms，基本可以确认已经出现了严重瓶颈。排查时要用iostat -dx 1来观察，别再盯着已经废弃的svctm；同时结合r_await和w_await，先分清问题出在读还是写，再配合/proc/diskstats以及调度器状态交叉核对，避免把“假瓶颈”误判成真问题。

iostat -x 里 await 是你要盯死的字段

Linux 没有“系统级 IO 平均响应延迟”这种全局汇总值，await 就是你要看的那个数——它代表每个 I/O 请求从发出到完成的平均耗时（单位毫秒），含排队时间 + 设备服务时间。别被 %util 或 tps 带偏。

实操建议：

• 必须加 -x 参数：iostat -dx 1，否则看不到 await
• 重点关注目标设备行（如 nvme0n1 或 sda），不是 totals 行
• HDD 超过 10ms、NVMe 超过 1ms 就该介入；持续 > 50ms 基本确认严重瓶颈
• svctm 字段已废弃（内核 2.6.34+ 不再更新），直接忽略

区分 r_await 和 w_await 才能定位读写瓶颈类型

r_await 和 w_await 分开告诉你读请求和写请求各自的平均延迟。它们差异大，说明问题不在磁盘本身，而在访问模式或上层逻辑。

常见场景：

• r_await 显著高于 w_await：查数据库全表扫描、日志归档读取、备份脚本加载大文件
• w_await 高但 w/s 很低：典型小写阻塞，比如每秒几十次 write(2) 调用，每次 4KB，却打满队列深度
• r_await 和 w_await 都高且接近：更可能是硬件链路（PCIe AER 错误）、驱动异常或调度器错配

iotop 和 pidstat 都安静，但 await 还很高？去 /proc/diskstats 看底层排队

当 iotop -oPa 和 pidstat -d 1 都显示进程 I/O 平稳，但 await 居高不下，说明 I/O 卡在块设备层以下——进程没在“主动”刷盘，但请求已在内核排队。

检查步骤：

• 执行 cat /proc/diskstats，记下目标设备第 9 列（a veq，加权队列长度）和第 11 列（await 的原始累加值）
• 等 5 秒再跑一次，看这两列是否明显增长：增长 = 真实排队，不增长 = 延迟毛刺或统计抖动
• 检查调度器：cat /sys/block/nvme0n1/queue/scheduler，NVMe 必须是 none，若为 mq-deadline 或 bfq，会人为引入串行化延迟
• 查硬件链路：dmesg | grep -i "nvme|ata|error|timeout"，ACPI 电源异常、PCIe 重试、链路降速都会导致 await 毛刺

ioping 测的是裸设备延迟，绕过缓存才真实

ioping 不走文件系统，直接对块设备发同步 I/O，测出来的是存储介质本身的响应能力，适合验证硬件是否达标。

关键用法：

• 安装后运行：ioping -C -c 10 /dev/nvme0n1，-C 强制同步写，确保落盘
• 关注输出中的 a vg 值：NVMe 应 < 0.2ms，SATA SSD 在 0.5–1.5ms 区间，HDD 正常是 5–15ms
• 如果 ioping 延迟正常，但 iostat 的 await 高，问题一定出在上层：文件系统、page cache 回写策略、I/O 调度器或应用行为