Linux怎么查看具体的IO平均响应延迟
await可以说是判断I/O延迟最关键的指标之一,它表示单个I/O请求从发起到完成的平均耗时,单位是毫秒,里面既包含排队时间,也包含真正的服务时间。一般来说,HDD一旦超过10ms、NVMe超过1ms,就该开始介入排查了;如果持续高于50ms,基本可以确认已经出现了严重瓶颈。排查时要用iostat
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 调度器或应用行为
/proc/diskstats 前后变化和检查 NVMe 的调度器设置——这两步不花时间,但能快速排除 70% 的“假瓶颈”。 

































