全闪存存储下Oracle RAC必须统一启用none调度器，因NVMe设备内建高效调度，绕过内核IO调度层可避免0.1–0.5ms额外延迟；混用调度策略会导致ASM元数据异常、gc cr block busy等待及I/O抖动，且需同步配置并持久化。
全闪存存储下Oracle RAC共享存储延迟高，大概率不是ASM或数据库层的问题，而是IO调度策略错配、硬件拓扑争用或NVMe设备磨损导致的——先查底层，再调参数。
为什么none调度器是必须统一启用的
Linux内核5.0+对NVMe设备默认使用none调度器（即绕过内核IO调度层），这是因NVMe控制器自身已具备高效队列管理和优先级调度能力。若某节点仍为deadline或mq-deadline，就会在IO路径上多加一层软件排队，引入0.1–0.5ms不等的额外延迟，且RAC节点间IO语义不一致会触发gc cr block busy和enq: TX - row lock contention等待。
- 确认当前调度器：
cat /sys/block/nvme0n1/queue/scheduler（把nvme0n1换成实际设备名） - 临时设置：
echo none > /sys/block/nvme0n1/queue/scheduler - 持久化：在
/etc/rc.local或systemd服务中加入该命令，确保重启后生效 - 所有RAC节点必须同步执行，
crsctl check cluster不报错 ≠ IO路径一致
PCIe拓扑与CPU socket绑定最容易被忽略
即使每块NVMe盘都是独立设备，若多个节点的NVMe设备都挂在同一个PCIe Root Complex下游（常见于OCP服务器或双路Xeon平台），带宽会被争抢，尤其在RAC rebalance或大量归档写入时，read_time在v$asm_disk_iostat中可能突增至5ms以上。
- 检查拓扑：
lspci -tv，确认各节点NVMe设备是否分散在不同CPU socket的PCIe Root Complex下 - 绑定建议：将节点1的NVMe挂载到CPU0直连PCIe插槽，节点2的挂到CPU1直连插槽
- 避免使用PCIe Switch扩展卡——它会成为隐性瓶颈，
smartctl -a /dev/nvme0n1中Percentage Used超过80%时延迟也会陡增
ASM_POWER_LIMIT设太高反而压垮NVMe队列深度
全闪存重建速度快，但NVMe设备队列深度有限（常见为64或128）。默认ASM_POWER_LIMIT=1太保守，但直接设为10可能让IO请求瞬间打满队列，引发free buffer waits和write complete waits。
- 建议起始值设为5，观察
v$asm_disk_iostat.read_time和write_time是否稳定在0.2ms以内 - 若
read_time持续＞0.5ms，说明IO已饱和，需回调至3或2 - 配合
DB_FILE_MULTIBLOCK_READ_COUNT从128降至32～64，避免单次发起过多IO请求 - 务必确认
filesystemio_options=SETALL，否则异步IO可能退化为同步
ASM磁盘组FAILGROUP未显式指定会放大跨节点GC流量
当ASM磁盘组跨多个NVMe设备但未定义FAILGROUP时，Oracle默认按物理盘顺序分组，可能导致同一镜像的两个拷贝落在不同节点可访问的NVMe盘上。此时ALTER DISKGROUP ... REBALANCE POWER 10会强制节点间大量搬运数据块，表现为gc current等待飙升、私网带宽打满。
- 建盘组时显式指定：
CREATE DISKGROUP DATA NORMAL REDUNDANCY FAILGROUP fg1 DISK '/dev/nvme0n1' FAILGROUP fg2 DISK '/dev/nvme1n1'; - 已有盘组可通过
ALTER DISKGROUP ... ADD FAILGROUP补救，但需停业务窗口 -
asmcmd lsdg中USABLE_FILE_MB出现非预期波动，往往是FAILGROUP配置不当的信号
真正卡住性能的，往往不是参数本身，而是节点间“看不见的一致性假设”——比如调度器类型、PCIe归属、FAILGROUP划分。这些地方一旦不一致，监控指标可能全绿，但延迟就是下不来。
