私有网卡支持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/能看到当前值，但这里有个关键陷阱：内核允许你设置成9000，并不等于硬件真的有能力收发9000字节的完整帧。/mtu - 最后，必须牢记一个原则：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来捕获RAC私网的UDP流量，观察是否真的出现了大于1500字节（比如8972）的数据包。-f “udp port 12560” -T fields -e frame.len | sort -u - 检查系统网络统计信息：运行
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）机制。这些细节如果没卡死，所谓的性能优化，恐怕就只是停留在纸面上的美好数据了。
