极客教程

Appearance

磁盘 I/O 指标 —— iostat 输出的 await、svctm、%util、r/s、w/s 全拆解 ​

上一篇 iowait.md 讲了 %iowait 在 CPU 维度的统计逻辑。本篇下沉到设备维度——iostat -x 1 输出的每一列分别代表什么？为什么 %util=100% 对 SSD 不意味着瓶颈？await 和 svctm 到底哪个可信？Queue depth 多大算大？回答 iostat 每一列的真实含义和排查用法。

更新时间：2026-08-06

一、iostat 输出全景 ​

bash
$ iostat -x 1
Device   r/s   w/s   rkB/s   wkB/s   await  r_await  w_await  svctm  %util
sda     10.0  20.0   500.0  1000.0    5.00    3.00     6.00   0.50   1.50
列名含义单位
r/s每秒完成的读请求数次/秒
w/s每秒完成的写请求数次/秒
rkB/s每秒读取的千字节数KB/s
wkB/s每秒写入的千字节数KB/s
await每个 I/O 请求的平均耗时（从发起请求到完成）ms
r_await读请求的平均耗时ms
w_await写请求的平均耗时ms
svctm（不可信，后文详述） 平均服务时间ms
%util设备繁忙时间百分比%
aqu-sz平均请求队列长度（iostat -x 通常显示此列）个

数据源：全部来自 /proc/diskstats（或 /sys/block/<dev>/stat），内核在块设备层的请求完成时更新这些计数器。iostat 两次采样差值除以采样间隔得到速率。

二、指标逐个详解 ​

2.1 r/s、w/s（IOPS，Input/Output Operations Per Second） ​

每秒完成的读写请求次数：

  • IOPS 高：小 I/O 密集（数据库随机读写、大量小文件操作）
  • IOPS 低：大 I/O 为主（流媒体顺序读写、日志追加）

参考基线（单盘）：

  • SATA HDD：~100-200 IOPS（随机读写）
  • SATA SSD：~5K-100K IOPS
  • NVMe SSD：~100K-1M IOPS

2.2 rkB/s、wkB/s（吞吐量） ​

每秒传输的数据量：

  • IOPS × 平均请求大小 = 吞吐量
  • 小 I/O 场景下 IOPS 先于吞吐量达到瓶颈
  • 大 I/O 场景下吞吐量先于 IOPS 达到瓶颈（受总线/接口带宽限制）

2.3 await（平均 I/O 响应时间）—— 最重要、最可靠 ​

await = IO 请求在队列中排队的时间 + 设备真正处理的时间
                                ^               ^
                          queue time      service time
  • await = 排队时间 + 服务时间
  • 这是从应用角度"发起 I/O 到 I/O 完成"的全链路延迟
  • 高 await = I/O 慢，这是用户真正感受到的延迟

参考基线：

设备类型正常 await需关注严重
HDD< 10ms10-30ms> 30ms
SATA SSD< 1ms1-5ms> 5ms
NVMe SSD< 0.5ms0.5-2ms> 2ms

2.4 svctm（平均服务时间）—— 不可信，不要用 ​

man iostat 已经明确标注：

svctm is not reliable and will be removed in a future version

原因：内核不再暴露准确的"单次设备服务时间"。svctm 是一个基于历史行为的粗糙估算——在并发 I/O（现代 SSD 下一切场景）完全不准。

替代方案：用 await 代替 svctm。如果非要了解设备端服务时间，使用 blktrace + btt 做精确分析。

2.5 %util（设备利用率） ​

%util = 设备处于繁忙状态的时间 / 采样总时间 × 100%

对 HDD：%util 接近 100% = 设备确实满了（单磁头一次只能服务一个请求）。

对 SSD / NVMe / RAID：%util = 100% 不意味着瓶颈！SSD 可以并行处理多个 I/O 请求（多通道 + NCQ）。%util=100% 只说明每个采样周期都有 I/O，不代表设备已经打到吞吐上限。

正确判断 SSD 瓶颈：看 await + IOPS（r/s + w/s）。await 升高且 IOPS 不再增长 → 设备瓶颈。

2.6 aqu-sz（平均队列深度） ​

aqu-sz = (采样周期内平均排队的请求数)
  • aqu-sz > 1 且持续增长：请求在排队，设备处理不过来
  • 结合 await 看：await 高 + aqu-sz 高 → 确实磁盘瓶颈；await 高 + aqu-sz 低 → 可能是设备本身响应慢（如云盘延迟）

三、关键排查模式 ​

模式一：HDD 随机 I/O 瓶颈 ​

r/s + w/s = 200, await = 40ms, %util = 100%, aqu-sz = 8

判断：HDD 物理极限（磁头寻道），200 IOPS 导致等待。方案：换 SSD / 加大 Page Cache / 应用层做 I/O 合并。

模式二：SSD 真瓶颈 ​

r/s + w/s = 80000, await = 0.8ms → 3ms（持续上升）, aqu-sz = 5+

判断：SSD IOPS 接近上限，await 升高。方案：确认 fio 基准下 SSD 的实际 IOPS，考虑 RAID 0 或换更高规格 NVMe。

模式三：看似瓶颈实际不是 ​

%util = 80%, await = 0.3ms, aqu-sz = 0.1, r/s + w/s = 50000

判断：SSD 完全健康，只是 I/O 持续不断而已。await 极低、aqu-sz 极低、IOPS 还有上升空间——这里不需要任何操作。

模式四：突发大 I/O 导致的延迟尖刺 ​

用 iostat -x 1 可能看不出来（1s 间隔太粗）。使用：

bash
# 每 100ms 采样
iostat -x 0.1 10

# 或者用 biosnoop 看到每个 I/O 的耗时
biosnoop-bpfcc

四、与进程级指标的联动 ​

设备维度进程维度判断逻辑
await 高iodelay（pidstat -d）高确认磁盘是瓶颈，且找到了哪个进程在等 I/O
await 正常iodelay 高可能是 I/O 提交后排队在更上层（文件系统层），需用 perf 看内核路径
r/s + w/s 高kB_rd/s + kB_wr/s（pidstat -d）高找到 I/O 量最大的进程

五、一句话总结 ​

磁盘 I/O 指标中 await 是最可靠、最直接的业务感知延迟——从应用发起请求到设备完成的整段耗时。%util 对 SSD 是失真的（100% 不意味着瓶颈），应结合 await + aqu-sz 判断。svctm 已被官方声明不可信，不要依赖它。进程级 iodelay 与设备级 await 联动排查，可以精确定位"哪个进程在等哪块盘"。