报错是这么冒出来的。同规格的 ESSD 盘，别人 fio 能跑三万 IOPS，这台只有八千，业务写入排队越来越长，可 CPU 和网络都不高。
原因不止一个，得分开看。分区起始扇区不是二零四八的整数倍，一次写会跨两个物理块。少数情况下是文件系统块大小与业务实际 IO 大小不匹配。
还有一种情况，云盘挂载后没有开多队列，队列深度根本上不去。
动手时先看分区起始扇区
parted -s /dev/vdb unit s print随后用 direct 模式测随机写
fio -name=t -rw=randwrite -bs=4k -direct=1 -filename=/dev/vdb1然后备份后按一 MiB 对齐重建
parted -s /dev/vdb mklabel gpt mkpart primary 1MiB 100%剩下的就是确认队列调度器与深度
cat /sys/block/vdb/queue/scheduler这类改动我都写进变更记录，过两周再出问题时能对上号。
恢复的判定其实很直接。重测 fio 的 IOPS 接近云盘标称值，业务写入的 p99 延迟明显下降并且能稳定保持。
这里还有个坑。对齐只能在建分区的时候做，事后调整等于重建；测试不加 direct 参数走的是缓存，数字没有任何参考意义。这类问题最好一次改到位，反复小改反而容易把原因搅混。