如何配置RAC私有网络的Jumbo Frames_MTU 9000提升缓存融合传输效率

私有网卡支持MTU 9000需硬件、驱动、交换机端到端协同；仅操作系统设MTU无效，RAC须停集群统一配置并验证UDP巨帧流量与分片情况。

私有网卡是否真的支持 MTU 9000？先查硬件和驱动

不少团队一上来就直接修改 ifconfig 或者执行 ip link set mtu 9000，结果发现节点间用 ping -m do -s 8972 测试失败，甚至整个RAC集群都启动不了。问题根源往往不在操作系统层面，而是底层压根不支持：可能是网卡型号太老、驱动程序没启用巨帧功能，或者交换机端口根本没开启 jumbo frames。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

• 第一步，用 ethtool 命令，重点查看 Supports jumbo frames 这一项是否为 yes。如果显示是 no，基本就得考虑升级驱动或者更换网卡了。
• 接着检查驱动加载参数。以常见的 ixgbe 驱动为例，需要确认 modinfo ixgbe | grep jumbo 的输出中包含 jumbo_frames 参数，并且默认是启用的。
• 通过 cat /sys/class/net//mtu 能看到当前值，但这里有个关键陷阱：内核允许你设置成9000，并不等于硬件真的有能力收发9000字节的完整帧。
• 最后，必须牢记一个原则：RAC私有网络需要所有节点、中间经过的每一台交换机、乃至可能使用的直连缆线（比如DAC）全部实现端到端的支持。只要其中一环掉了链子，整个链路就会退化成标准帧传输。

Oracle RAC 私网配置 MTU 的正确顺序

调整RAC私网MTU，可不能只盯着操作系统这一层。Clusterware和ASM实例在启动时会读取网络配置，如果各个节点的私网MTU设置不一致或者没有同步生效，即便 crsctl check cluster 命令能通过，oifcfg getif 显示出来的接口MTU也可能与实际不符。结果就是，本该高效传输的cache fusion数据包被强行分片，性能不升反降。

• 正确的起点是停止集群：在所有节点上执行 crsctl stop crs。
• 然后统一设置MTU：使用 ip link set dev mtu 9000 命令（建议避免使用 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 -f “udp port 12560” -T fields -e frame.len | sort -u 来捕获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个、且平均的全局缓存请求块大小（global cache cr request）较大时，如果原MTU是1500，那么启用MTU 9000可能带来15%到25%的性能提升。

• 切忌在混合速率的网络中强行推广：比如私有网络一部分是支持9000 MTU的10GbE链路，另一部分却是仅支持1500 MTU的旧1GbE交换机，那么整个私网会以最低标准运行，巨帧优势荡然无存。
• 如果ASM实例（+ASM）的日志里持续出现 “IPC send timeout” 这类错误，稳妥的做法是先回退MTU设置，再排查问题。因为巨帧会放大丢包带来的影响。
• 从Oracle 19c版本开始，默认启用了 _gc_use_largesend 参数，但这个参数能否真正生效，完全依赖于底层MTU的支持和UDP协议栈的行为，不是单独打开就能万事大吉的。
• 巨帧带来的真正收益，往往不在于节省了多少带宽，而在于减少了网络中断次数和CPU处理softirq（软中断）的开销。所以，用 vmstat 1 命令观察 si（softirq）列的下降趋势，比单纯看网络吞吐量更能准确反映优化效果。

最后提一个最常被忽略的步骤：修改完MTU后，不仅要验证UDP包长度是否真的变大了，还得记得检查并关闭交换机上可能引发缓冲区溢出的流控（flow control）机制。这些细节如果没卡死，所谓的性能优化，恐怕就只是停留在纸面上的美好数据了。