直接改MTU=9000不等于私网延迟下降，必须端到端一致支持Jumbo Frames、UDP流量真实走巨帧、Oracle进程读取新缓冲区值三者齐备；否则查网卡驱动、停集群统一配置、抓包验证分片与缓冲区缺一不可。
直接改 mtu=9000 不等于私网延迟下降——端到端不一致、udp 流量未走巨帧、oracle 进程没读新缓冲区值，三者漏一，全白配。
查网卡和驱动是否真支持 Jumbo Frames
很多团队在 ip link set dev eth1 mtu 9000 后就以为搞定，结果 ping -M do -s 8972 -I eth1 <remote_node></remote_node> 直接失败。根本不在配置层，而在硬件链路层。
- 用
ethtool eth1看Supports jumbo frames: Yes—— 若为No，换驱动或网卡（如老版e1000e默认关 jumbo） - 查驱动参数：
modinfo ixgbe | grep jumbo应输出含jumbo_frames且默认启用；若未启用，需加options ixgbe jumbo_frames=1到/etc/modprobe.d/ixgbe.conf -
cat /sys/class/net/eth1/mtu只反映内核允许设的值，不等于网卡能收发 9000 字节帧；必须配合ping -M do -s 8972实测
RAC 私网 MTU 必须停集群统一设，滚动生效无效
Oracle Clusterware 和 LMS 进程启动时硬读接口 MTU 值，运行中改 ip link set 不触发重协商。曾有案例：节点1重启后 ASM 启动报 ORA-15032: not all alterations performed，alert 明确提示 “remote interconnect MTU mismatch: local=9000, remote=1500”。
- 必须先执行
crsctl stop crs（所有节点） - 再统一执行
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 设对了，不代表 Oracle 的 GCS/GES 流量就自动变大包。默认仍可能拆成多个 UDP 小包，尤其当隐含参数未调或内核缓冲区太小。
- 抓包确认：
tshark -i eth1 -f "udp port 12560" -T fields -e frame.len | sort -u—— 出现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 进程启动后才读该值，必须重启数据库实例
别忽略交换机和物理链路的隐性瓶颈
万兆网卡标称带宽 ≠ RAC 私网可用带宽。实测 netperf -H <remote> -t UDP_STREAM -l 60</remote> 若低于 7 Gbps，问题大概率不在 Oracle 配置。
- 交换机端口必须显式启用 jumbo frame（如 Cisco：
system jumbomtu 9000；HPE Aruba：ip mtu 9000），仅设接口 MTU 不够 - 直连 DAC 线缆或光纤模块也需支持 9000 字节帧；老旧 DAC 常限 1500，插上就退化
- 检查网卡中断合并：
ethtool -c eth1，若rx-usecs/tx-usecs为 0，说明每包中断一次，ethtool -C eth1 rx-usecs 50 tx-usecs 50可降软中断压力
真正难的不是把 mtu 改成 9000，而是让从 Oracle 的 LMS 进程发包、到网卡驱动封装、经交换机转发、再到远端网卡接收、最后进内核 UDP 缓冲区这一整条链路上，每个环节都对齐且无隐式截断——少验一环，延迟照旧。
