rrqm/s 和 wrqm/s 是 iostat -x 中唯一直接反映 io 合并行为的字段，表示每秒被调度器合并掉的读/写请求数，值为 0 不代表无合并；验证真实合并应结合 blktrace 抓取 m 标记事件，并辅以 avgrq-sz 升高、r_await 下降等间接指标。
怎么用 iostat -x 看请求合并是否发生
rrqm/s 和 wrqm/s 是唯一直接体现合并行为的字段，但它们不是“省掉了多少请求”，而是“进队列前被调度器当场合并掉的次数”。值为 0 不等于没合并——比如 IO 地址太散、队列太浅、或请求刚进 queue 就被派发，根本没排队机会。
真正验证合并是否生效，得看 avgrq-sz（平均请求大小）：HDD 上长期 >64 扇区（即 >32KB）通常说明合并起了作用；NVMe 上这个值可能偏低，因多队列设计天然削弱合并效果。
- 若
r/s很高但rkB/s很低，说明小请求泛滥，合并大概率失效 -
avgqu-sz持续低于 1 且r/s居高不下，提示 IO 过于离散，合并难发生 -
r_await明显下降 +rrqm/s同步上升，是合并起效的强信号
为什么改了 /sys/block/sda/queue/nomerges 没变化
修改这个参数后 rrqm/s 不变，常见原因有三个：
- IO 走的是 LVM 或加密层（如
dm-0），你改了sda，但实际设备是dm-0，应检查并改/sys/block/dm-0/queue/nomerges - 应用用了
O_DIRECT或posix_fadvise(POSIX_FADV_DONTNEED)，绕过了页缓存，合并机会大幅减少 - writeback 机制延迟提交写请求，
iostat统计的是最终下发到块层的 request，不是系统调用层面的 IO
怎么用 blktrace 确认真实合并事件
blktrace 是唯一能抓到底层合并动作的工具。运行命令需 root 权限，且会短暂影响 IO 性能：
blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'M'
只要输出里有带 M（merged）标记的行，就证明发生了前向或后向合并。注意：M 标记出现在 blkparse 输出的第三列，格式类似 8,0 1 0 0.000000000 2048 M R 0 () + 8 [kworker/u8:2]。
别只盯着 rrqm/s 数值——它反映的是“合并尝试次数”，而 blktrace 抓到的 M 才是“合并成功事件”。
%util 高不代表磁盘真忙，但和合并效率强相关
%util 是队列非空时间占比，不是吞吐瓶颈指标。当它接近 100% 时，有两种可能：
- 真实 I/O 压力大，请求排队严重 → 此时若
rrqm/s和avgrq-sz同步升高，说明合并在缓解排队压力 - 请求太小太碎，大量短 IO 把队列“打满” → 此时
rrqm/s接近 0，avgrq-sz极低，avgqu-sz却很高，是合并失效的典型症状
真正要盯的不是 %util 本身，而是它和 rrqm/s、avgrq-sz 的组合关系——合并效率低时，哪怕吞吐量不大，%util 也可能虚高。
