私有网卡支持MTU 9000需硬件、驱动、交换机端到端协同；仅操作系统设MTU无效，RAC须停集群统一配置并验证UDP巨帧流量与分片情况。
私有网卡是否真的支持 MTU 9000？先查硬件和驱动
很多团队直接改 ifconfig 或 ip link set mtu 9000，结果发现节点间 ping -m do -s 8972 失败，甚至 rac 启动失败。根本原因常是底层不支持：网卡型号老旧、驱动未启用巨帧、交换机端口没开 jumbo frames。
- 用
ethtool <interface></interface>查看Supports jumbo frames是否为yes；若为no，换驱动或网卡 - 检查驱动加载参数，比如
ixgbe需确认modinfo ixgbe | grep jumbo输出含jumbo_frames且默认启用 -
cat /sys/class/net/<interface>/mtu</interface>看当前值，但注意：内核允许设 9000 ≠ 硬件真能收发 9000 字节的帧 - RAC 私网必须所有节点、中间交换机、可能的直连线缆（如 DAC）全部端到端支持，漏一环就退化成标准帧
Oracle RAC 私网配置 MTU 的正确顺序
不能只调操作系统层。RAC 的 Clusterware 和 ASM 实例在启动时会读取网络配置，若私网 MTU 不一致或未同步生效，crsctl check cluster 可能通过，但 oifcfg getif 显示的接口 MTU 和实际不符，导致 cache fusion 包被分片，反而降低效率。
- 先停集群：
crsctl stop crs（所有节点） - 再统一设 MTU：
ip link set dev <private_if> mtu 9000</private_if>（别用ifconfig，它不持久且部分版本不生效） - 确认
sysctl net.ipv4.ip_forward = 0（私网必须关转发，否则可能干扰 UDP 包路径） - 重启集群前，用
cluvfy comp nodecon -n all -verbose检查私网连通性与 MTU 一致性
为什么改了 MTU，cache fusion 还没变快？看真实流量是否走巨帧
即使配置全对，Oracle 默认仍可能用小包发 GES/GCS 请求——因为 _gc_affinity_time、_gc_read_mostly_locking 等隐含参数影响包合并行为，而 TCP MSS 协商或 UDP 包大小限制也可能压制效果。
- 用
tshark -i <private_if> -f "udp port 12560" -T fields -e frame.len | sort -u</private_if>抓 RAC 私网 UDP 流量，看是否真出现 >1500 字节的包（如 8972） - 检查
netstat -s | grep -i "fragments"，若reasm fails或frag creates持续增长，说明仍有分片，链路某处 MTU 卡在 1500 - 确认 Oracle 使用的是 UDP（非 TCP）传输：查
lsof -i :12560，输出应含UDP；若看到TCP，说明_use_adaptive_networking被关闭或网络异常触发回退 -
oradebug setmypid; oradebug dump events 10000后查 alert 日志，确认 GCS 是否报告"large message"相关统计上升
MTU 9000 对 RAC 的真实收益边界在哪？
不是所有环境都适合。当私网带宽充足（如双 10GbE）、节点数 ≤ 4、平均 block request size global cache cr request，且原 MTU 是 1500，收益可达 15–25%。
- 不要在混合速率网络中强推：比如私网一部分是 10GbE（支持 9000），另一部分是旧 1GbE 交换机（仅支持 1500），整个私网会降级
- ASM 实例的
+ASM日志里若持续出现"IPC send timeout"，先 revert MTU 再排查，巨帧放大丢包影响 - Oracle 19c+ 默认启用
_gc_use_largesend，但该参数依赖底层 MTU 和 UDP 栈行为，不能单独打开就起效 - 真正省下的不是带宽，是中断次数和 CPU softirq 开销——所以
vmstat 1看si（softirq）下降比看吞吐更准
最常被跳过的步骤：改完 MTU 后没验证 UDP 包长是否真变大，也没关掉交换机上的 flow control（它和巨帧共存时可能引发 buffer overflow）。这些点不卡死，优化就只是纸面数据。
