90%的cache fusion巨帧优化失败源于硬件支持不足、端到端mtu不一致或oracle未实际使用巨帧；需逐层验证网卡驱动、交换机配置、直连缆规格，并停集群统一设置mtu，再抓包确认udp gc流量帧长是否达8972字节。
直接改 ip link set dev eth1 mtu 9000 不等于 cache fusion 就变快了——90% 的失败案例卡在硬件支持、端到端一致性或 oracle 没真用上巨帧这三关。
查网卡和驱动是否真支持 jumbo frames
内核允许设 mtu 9000，不代表网卡能收发 9000 字节的帧。必须逐层验证：
- 运行
ethtool eth1，确认输出中Supports jumbo frames: Yes；若为No，换驱动或网卡是唯一出路 - 检查驱动参数：比如
ixgbe驱动需有jumbo_frames参数且默认启用，执行modinfo ixgbe | grep jumbo看是否含该字段 - 查看当前 MTU 值只是表象，
cat /sys/class/net/eth1/mtu显示 9000 ≠ 硬件生效，它只是内核软设置 - Solaris 用户注意：
dladm show-linkprop -p mtu中POSSIBLE范围上限必须 ≥9000，否则需改/kernel/drv/igb.conf的default_mtu
所有节点 + 交换机 + 直连线缆必须端到端一致
RAC 私网是链路敏感型通道，一环掉链子，整条链路退化回 MTU 1500：
- 每个 RAC 节点的私网接口都得设成
mtu 9000，不能只调一个节点 - 中间所有交换机端口（包括堆叠、级联口）必须显式开启 jumbo frames，常见命令如 Cisco 的
system jumbomtu 9000、Juniper 的set interfaces xe-0/0/0 mtu 9000 - 如果用 DAC（直连铜缆），确认其规格支持 9000 字节帧；部分老型号 DAC 只支持 ≤2000 字节，会静默丢包
- 用
ping -M do -s 8972 -I eth1 remote_node_ip测试——8972 是 UDP 载荷最大值（9000 − 8 字节 ICMP 头 − 20 字节 IP 头），失败即说明某处不支持
停集群后统一配置，别信“滚动生效”
Oracle Clusterware 和 ASM 在启动时固化网络配置，运行中改 MTU 对已启动实例无效，且可能引发驱逐：
- 必须在所有节点执行
crsctl stop crs，彻底停止集群后再设 MTU - 用
ip link set dev eth1 mtu 9000设置，避免ifconfig—— 它在某些内核版本不持久，且无法触发底层驱动重初始化 - 确认
sysctl net.ipv4.ip_forward = 0，私网开启转发会导致 UDP 包路径异常，干扰 GCS/GES 流量 - 重启前运行
cluvfy comp nodecon -n all -verbose，检查私网连通性与 MTU 一致性；若报告不一致，别硬启
验证 Oracle 是否真在用巨帧发 GC 包
配置全对，但 Oracle 默认仍可能发小包——GC 流量走的是 UDP（端口通常为 12560），不是 TCP，得抓包看真实帧长：
- 用
tshark -i eth1 -f "udp port 12560" -T fields -e frame.len | sort -u抓流量，出现8972或接近该值的帧长才表示巨帧生效 - 查
netstat -s | grep -i "frag"，若reasm fails或frag creates持续增长，说明仍有分片，链路某处 MTU 实际卡在 1500 - 确认协议：运行
lsof -i :12560，输出必须含UDP；若看到TCP，说明_use_adaptive_networking被关或网络异常触发回退 - 查 alert.log：执行
oradebug setmypid; oradebug dump events 10000后，搜索 “large message”，若统计上升，说明 GC 层确实在尝试发大包
最常被跳过的一步是交换机端口配置——很多人只改服务器 MTU，却忘了交换机默认关闭 jumbo frames，结果所有努力都白费；还有人用 ping 测试成功就以为万事大吉，但 Oracle GC 用的是 UDP + 自定义端口，必须针对性抓包验证。
