cache fusion延迟主要受物理链路、内核协议栈和oracle进程读取时机制约，调db_cache_size或gc_*参数无效；需实测巨帧（mtu=9000）端到端生效，统一停集群设mtu并验证连通性与分片情况。
直接调大 db_cache_size 或改 gc_* 隐含参数，对私网延迟几乎没用——Cache Fusion 延迟卡在物理链路、内核协议栈和 Oracle 进程读取时机上，不是数据库内存层能调出来的。
验证私网是否真走巨帧（Jumbo Frame）
MTU=9000 配了≠生效，UDP 流量仍可能被拆成 1500 字节小包，导致大量分片与重组开销。
- 用
ping -M do -s 8972 -I <private_if><remote_node_private_ip></remote_node_private_ip></private_if>实测：失败说明链路某处不支持巨帧（交换机端口、网卡驱动、光纤模块都可能拦住） - 查网卡真实能力：
ethtool <private_if></private_if>看Supports jumbo frames: Yes；若为No，得换驱动或网卡（如老版e1000e默认关 jumbo） - 查驱动参数：
modinfo ixgbe | grep jumbo_frames，若未启用，需加options ixgbe jumbo_frames=1到/etc/modprobe.d/ixgbe.conf -
cat /sys/class/net/<private_if>/mtu</private_if>只反映内核允许值，不等于硬件能收发 9000 字节帧——必须实测通过才算数
停集群统一设 MTU，滚动生效无效
Oracle Clusterware 和 LMS 进程启动时硬读接口 MTU 值，运行中执行 ip link set dev <private_if> mtu 9000</private_if> 不触发重协商，节点间 MTU 不一致会直接报 ORA-15032 或驱逐。
- 必须先
crsctl stop crs（所有节点），再统一执行ip link set dev <private_if> mtu 9000</private_if>（禁用ifconfig，它不持久且部分内核不生效） - 启动前跑
cluvfy comp nodecon -n all -verbose，确认各节点 MTU 值与连通性一致 - 检查
sysctl net.ipv4.ip_forward = 0——私网必须关转发，否则 UDP 包可能被误路由
抓包确认 GC 流量是否真用巨帧
配置对了，不代表 GCS/GES 的 UDP 包就自动变大。默认仍可能拆成多个小包，尤其当内核缓冲区太小或隐含参数未调。
- 抓包看真实帧长：
tshark -i <private_if> -f "udp port 12560" -T fields -e frame.len | sort -u</private_if>，出现8972或接近值才算成功；若全是1500左右，说明链路某处卡在 1500（常见于交换机端口未开 jumbo） - 查分片情况：
netstat -s | grep -i "frag\|reassemble"，若reasm fails或frag creates持续涨，就是分片失败，链路不完整 - 查 UDP 接收缓冲区：
cat /proc/sys/net/core/rmem_max，若，需设为 <code>25165824并sysctl -p；但注意：LMS 进程启动后才读该值，必须重启数据库实例
别忽略交换机与底层物理约束
哪怕服务器和网卡全配对，交换机一个端口没开 jumbo，整条链路就退化回 1500；Extended RAC 场景下，光速限制让 100km 距离 RTT 难压到 3ms 内，此时调任何 Oracle 参数都是徒劳。
- 所有交换机端口必须显式启用 Jumbo Frame（非默认），并确认跨设备二层透传无阻断
- 远距离部署必须由网络团队出具书面报告：
ping -s 8192持续 1 小时，最大 RTT ≤ 2.5ms 且零丢包 - FC 或 InfiniBand 网络必须打通跨机房大二层，RAC 节点能互相
arp到对方私网 MAC 地址——不能靠三层路由
真正卡住 Cache Fusion 延迟的，从来不是 SQL 或内存参数，而是你没看到的那几微秒分片重组、那一毫秒内核缓冲区拷贝、还有交换机端口上静默丢弃的巨帧。这些地方一漏，MTU 改得再漂亮也没用。
