Linux怎么查看具体的磁盘读写请求合并效率实时指标
看磁盘 IO,不能只盯着吞吐量,一定要结合 iostat -x 去看 rrqm/s 和 wrqm/s。这两个指标,说白了就是内核在读写请求上的合并效率。一般来说,rrqm/s 偏高,往往意味着随机读比较密集;如果 wrqm/s 已经接近 w/s 的一半甚至更高,通常就说明写入碎片化已经比较严重了。再
看磁盘 IO,不能只盯着吞吐量,一定要结合 iostat -x 去看 rrqm/s 和 wrqm/s。这两个指标,说白了就是内核在读写请求上的合并效率。一般来说,rrqm/s 偏高,往往意味着随机读比较密集;如果 wrqm/s 已经接近 w/s 的一半甚至更高,通常就说明写入碎片化已经比较严重了。再往下看,r/s 和 r_ios 之间的差异,其实也能反映内核的合并强度:差值越大,越能说明底层跑的是小块随机 IO。

看 rrqm/s 和 wrqm/s 字段必须用 iostat -x
这两个值直接告诉你内核对读/写请求的合并效率,但只在 iostat -x 模式下输出。默认 iostat 或加 -d 参数时完全不显示它们。
执行命令:iostat -x 1(每秒刷新),重点关注输出中的 rrqm/s(每秒被合并的读请求数)和 wrqm/s(每秒被合并的写请求数)两列。
rrqm/s高 ≠ 好:说明上层发来大量小读请求,内核被迫频繁合并,往往意味着随机读密集、IO模式低效wrqm/s接近w/s一半以上:写请求碎片化严重,可能是日志类应用未批量刷盘,或文件系统未启用 writeback 缓存- SSD 上
rrqm/s通常远低于 HDD:因为 SSD 随机读延迟低,应用更倾向发小请求,合并动力弱 - 值为 0 不代表没合并:只是“被显式合并”的请求数为 0,底层 block layer 仍可能做隐式合并(比如 NVMe 提交 batch)
r/s 和 r_ios 差异暴露真实下发压力
r/s 是上层合并后提交到队列的请求数,r_ios(需 iostat -dx)才是真正送进 block queue 的次数。两者差距就是“内核级合并强度”的量化体现。
例如某 NVMe 盘:r/s 显示 120,但 r_ios 是 4800 —— 说明平均每个 r/s 请求背后有 40 个小 IO 被内核打包提交。
- 这个差值越大,越说明 workload 是小块随机型(如数据库 redo log、小文件元数据操作)
- 如果
r_ios≈r/s,但rkB/s很低,大概率是应用层发了大量 512B/4K 对齐不良的请求,触发了额外切分 r_ios不能直接等同于物理完成数:驱动或设备固件可能再合并(比如 NVMe 多队列中一个 request 包含多个 cmd),要验证得查/sys/block/nvme0n1/stat第 1 列
别信 a vgrq-sz,它只反映逻辑请求大小
a vgrq-sz 单位是扇区(512B),看起来是“平均请求大小”,但它统计的是提交到 queue 前的逻辑请求尺寸,不包含合并后的真实物理 I/O 大小。
- 即使
a vgrq-sz显示 128(即 64KB),r_ios仍可能高达r/s的 10 倍——因为内核把 10 个 64KB 请求合并成 1 个 640KB request 下发 - 该值受文件系统块大小、应用 writev() 调用粒度、page cache 回写策略共同影响,单独看意义有限
- 真正关心吞吐效率时,应交叉比对:
rkB/s ÷ r_ios≈ 实际下发的平均物理 IO 大小(单位 KB)
合并效率异常时的典型错误现象
当请求合并失常,你不会看到“合并失败”报错,但会观察到一系列间接症状:
%util很高(>90%),但rkB/s很低:说明设备忙于处理海量小请求,而非传输数据r_await显著高于w_await:小读请求无法有效合并,排队时间拉长;而写请求常被 buffer/cache 暂存,实际下发节奏平滑a vgqu-sz突增但r/s没涨:队列里塞满待合并的小请求,内核还没来得及打包就又来了新请求- 用
fio --rw=randread --bs=4k测出 IOPS 极低,但换--bs=128k瞬间翻倍:证实小块场景下合并机制未起效或路径阻塞
很多人恰恰会忽略这一点:合并并不是只发生在某一个点上,它会横跨 VFS → block layer → driver 这几个层级。iostat 能看到的,其实只是 block layer 入口这一段的状态;至于进入驱动之后有没有继续被拆分、重组,就不是它的观察范围了,这类情况通常得借助 blktrace 或设备厂商提供的工具来进一步确认。
































