在 iostat -x 的所有字段里，rrqm/s 和 wrqm/s 是少数能直接看出 IO 合并情况的指标。它们表示的是：每秒有多少读/写请求在进入设备前被调度器合并掉。这里有个很容易搞混的点——它统计的不是“合并后总共少了多少请求”，而是“有多少请求参与了合并”。另外，数值显示为 0，也不能简单理解成完全没有发生合并；也可能是因为队列太浅、访问地址过于分散，或者请求派发得太快，来不及进入排队阶段就被处理掉了。真要确认合并有没有实际发生，还是得配合 blktrace 来看：blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'M'，只要看到 M 标记，就说明合并确实发生过。
怎么用 iostat -x 看真实合并效率
rrqm/s 和 wrqm/s 是唯一直接标示合并行为的字段，但它们不是“省掉了多少请求”，而是“调度器在进队列前主动合并掉的次数”。值为 0 不代表没合并——可能因为 IO 太零散、队列太浅，或者请求刚进就发走了，根本没排队机会。
真正反映合并效果的是间接指标：
a vgrq-sz：平均请求大小（扇区数）。HDD 上长期 >64（即 >32KB）说明合并较充分；SSD 上该值偏低也属正常，因原生支持小请求并发a vgqu-sz：平均队列长度。相同吞吐下，a vgqu-sz越低，通常意味着合并越有效（请求变少、队列压力下降）r_await/w_await：若合并起作用，等待时间会下降——但要注意，svctm才是纯设备处理时间，await - svctm才是排队等待部分
为什么改了 /sys/block/sda/queue/nomerges 没变化
写入 nomerges 后 rrqm/s 和 wrqm/s 无响应，常见原因有：
- 后台 writeback 机制在起作用：应用层
write()调用后数据先落页缓存，合并发生在 page cache 层或 flush 阶段，iostat统计的是最终下发到块层的 request，不是 syscall - IO 类型不触发合并：随机小 IO（如数据库 WAL 写）、direct I/O、O_SYNC 文件写，绕过页缓存，调度器合并窗口极小甚至关闭
- 设备类型限制：NVMe 设备默认启用
none调度器，nomerges对其无效；而某些 SCSI 控制器固件会忽略内核合并指令
用 blktrace 验证合并是否真发生
iostat 的数值容易误判，要确认合并是否实际发生，必须看块层原始事件流：
- 执行：
sudo blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'M' - 输出中每行带
M标记（merged）即表示一次前向或后向合并完成 - 注意：
blktrace需 root 权限，且会短暂增加 I/O 延迟，别在高负载生产环境长时间运行 - 若完全无
M行，再结合a vgrq-sz持续 ≤8（即 ≤4KB），基本可断定当前负载下无有效合并
a vgrq-sz 和扇区利用率的关系
a vgrq-sz 是扇区数，1 扇区 = 512 字节（传统扇区），但现代设备多用逻辑扇区 4K。它本身不等于“扇区利用率”，但能反推底层对齐情况：
- 若
a vgrq-sz长期为 8、16、32、64 等 2 的幂次，大概率说明上层 IO 对齐良好（如文件系统 block size 与物理扇区匹配） - 若
a vgrq-sz出现大量非整数倍（如 9、17、33），往往意味着跨扇区读写，引发读-改-写（R-M-W）放大，实际扇区擦写量远超逻辑数据量 - SSD 场景下，
a vgrq-sz过低（<16）+%util高 +await波动大，可能是 FTL 层内部碎片化导致写放大，此时需查厂商工具（如smartctl -a）而非只盯iostat
合并是否生效，不能只看一个数字。rrqm/s 是入口信号，a vgrq-sz 是结果快照，blktrace 是证据链——三者不一致时，优先信 blktrace 的 M 行。
