Linux怎么查看具体的磁盘读写请求合并效率及扇区利用率指标

在 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 行。