rrqm/s 和 wrqm/s 是 iostat -x 中唯一直接反映 io 合并行为的字段，表示每秒被调度器合并掉的读/写请求数，并非合并后减少的请求数；值为 0 不代表无合并，可能因队列浅、地址分散或派发过快导致未排队即处理；验证合并是否真实发生应结合 blktrace：blktrace -d /dev/sda -w 5 -o - | blkparse | grep 'm'，出现 m 标记即证实合并。
怎么用 iostat -x 看真实合并效率
rrqm/s 和 wrqm/s 是唯一直接标示合并行为的字段，但它们不是“省掉了多少请求”，而是“调度器在进队列前主动合并掉的次数”。值为 0 不代表没合并——可能因为 IO 太零散、队列太浅，或者请求刚进就发走了，根本没排队机会。
真正反映合并效果的是间接指标：
-
avgrq-sz：平均请求大小（扇区数）。HDD 上长期 >64（即 >32KB）说明合并较充分；SSD 上该值偏低也属正常，因原生支持小请求并发 -
avgqu-sz：平均队列长度。相同吞吐下，avgqu-sz越低，通常意味着合并越有效（请求变少、队列压力下降） -
r_await/w_await：若合并起作用，等待时间会下降——但要注意，svctm才是纯设备处理时间，await - svctm才是排队等待部分
为什么改了 /sys/block/sda/queue/nomerges 没变化
写入 nomerges 后 rrqm/s 和 wrqm/s 无响应，常见原因有：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 后台 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行，再结合avgrq-sz持续 ≤8（即 ≤4KB），基本可断定当前负载下无有效合并
avgrq-sz 和扇区利用率的关系
avgrq-sz 是扇区数，1 扇区 = 512 字节（传统扇区），但现代设备多用逻辑扇区 4K。它本身不等于“扇区利用率”，但能反推底层对齐情况：
- 若
avgrq-sz长期为 8、16、32、64 等 2 的幂次，大概率说明上层 IO 对齐良好（如文件系统 block size 与物理扇区匹配） - 若
avgrq-sz出现大量非整数倍（如 9、17、33），往往意味着跨扇区读写，引发读-改-写（R-M-W）放大，实际扇区擦写量远超逻辑数据量 - SSD 场景下，
avgrq-sz过低（%util 高 +await波动大，可能是 FTL 层内部碎片化导致写放大，此时需查厂商工具（如smartctl -a）而非只盯iostat
合并是否生效，不能只看一个数字。rrqm/s 是入口信号，avgrq-sz 是结果快照，blktrace 是证据链——三者不一致时，优先信 blktrace 的 M 行。
