Linux怎么查看具体的磁盘读写请求合并效率实时指标

看磁盘 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 或设备厂商提供的工具来进一步确认。