那么，究竟应该选择哪种I/O调度器呢？ 全闪存存储，尤其是NVMe设备，其I/O处理逻辑与传统的机械硬盘截然不同。`deadline`和`cfq`这类调度器原本是为优化磁盘旋转与磁头寻道而设计，应用于闪存存储只会徒增延迟。Linux内核5.0及以上版本对NVMe设备默认已启用`none`调度器（即直接绕过内核I/O调度层），这是最合理的选择。但如果你的系统仍运行在较老的内核（例如4.x系列），则需要手动确认并设置： `echo none > /sys/block/nvme0n1/queue/scheduler` 请注意，命令中的`nvme0n1`为示例设备名，实际使用时请替换为你的NVMe设备名称。通过`lsblk -d -o name,rota`命令可以快速识别——输出中`rota=0`的即为固态类设备。
然而，这仅仅是第一步。真正的关键在于：RAC集群中多个节点能否各自采用不同的I/O调度策略？ 答案非常明确：绝对不行。 RAC集群的所有节点对于同一个ASM磁盘组的I/O路径语义必须保持完全一致。如果节点A使用了`none`，而节点B仍在使用`deadline`，那么你很可能会遇到以下问题： * ASM在重平衡（rebalance）过程中，元数据同步会发生异常，`v$asm_operation`可能卡死在`REBAL`状态，无法继续推进。 * 节点间的I/O延迟会显著放大，进而引发`gc cr block busy`或`enq: TX - row lock contention`等棘手的等待事件。 * 更隐蔽的是，`crsctl check cluster`检查结果看似正常，但在`asmcmd lsdg`中，`USABLE_FILE_MB`指标却会出现异常波动。 因此，必须在所有RAC节点上统一执行调度器设置，并且务必将其写入`/etc/rc.local`或通过systemd服务固化，确保重启后配置依然生效。
当I/O调度器对齐后，还需要同步调整Oracle自身的参数，实现联动优化。 尽管底层延迟已经极低，但如果Oracle仍沿用传统机械盘的I/O批处理方式，就容易产生“小IO堆积”的问题。建议同步调整以下参数： * **`DB_FILE_MULTIBLOCK_READ_COUNT`**：建议从默认的128降低至32到64。这样能避免一次性发起过多I/O请求，防止压垮NVMe的队列深度。 * **`DISK_ASYNCH_IO`**：保持`TRUE`不变。但还需确认`filesystemio_options`是否设置为`SETALL`——否则异步I/O可能悄然退化为同步，导致性能大幅下降。 * **`ASM_POWER_LIMIT`**：全闪存的重建速度极快，理论上可以将参数设为10（默认值为1）。但必须同步监控`v$asm_disk_iostat`中的`read_time`指标，若出现突然飙升，说明I/O队列已饱和，需果断回调。 * **`_disk_sector_size_override`**：这是一个容易被忽视的细节。如果使用NVMe SSD，而`v$asm_disk.sector_size`返回的是512（实际物理扇区为4K），则需要将此隐含参数设置为`4096`。否则，ASM的条带化对齐将失效，影响性能表现。
最后，硬件层面还有一个极易被忽略的陷阱。 全闪存性能并非简单的线性叠加，尤其是在RAC多节点同时争抢资源时，问题会更加突出。 * **PCIe Switch拓扑**：如果NVMe设备挂在同一个PCIe Switch下游（这在OCP服务器中很常见），带宽可能被多个节点抢占。建议先用`lspci -tv`检查拓扑结构，最佳方案是将不同节点的NVMe盘分配到不同CPU socket的PCIe Root Complex下。 * **SSD磨损状态**：别忘了使用`smartctl -a /dev/nvme0n1`检查`Percentage Used`指标。如果已超过80%，高磨损的NVMe盘延迟会变得非常陡峭且不可预测。 * **ASM的FAILGROUP**：如果ASM磁盘组跨多个NVMe设备，且未显式指定`FAILGROUP`，则执行`ALTER DISKGROUP ... REBALANCE POWER 10`时，容易触发节点间大量`gc current block 2-way`流量。应当始终按物理控制器边界划分`FAILGROUP`，从而将不必要的跨节点通信降至最低。
