直接设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>直接失败。问题不在配置层，而在硬件链路层。
- 用
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实测
停集群统一设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（禁用ifconfig，它不持久且部分内核版本不生效） - 检查
sysctl net.ipv4.ip_forward = 0——私网必须关转发，否则UDP包可能被误路由 - 启动前跑
cluvfy comp nodecon -n all -verbose，确认MTU值与连通性一致
抓包确认UDP流量是否真走巨帧
MTU设对了，不代表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，若< 24M，需设为25165824并sysctl -p；但注意：LMS进程启动后才读该值，必须重启数据库实例
别忽略交换机和物理链路
私网必须经交换机，不支持交叉线直连；若共用业务交换机，务必用VLAN隔离。交换机端口MTU、流控、巨型帧开关、反向路径过滤（rp_filter）都得对齐。
- 确认交换机端口已开启Jumbo Frame（不同厂商命令不同，如Cisco是
system jumbomtu 9000，HPE是interface <port> jumbo</port>） - 禁用私网接口的
rp_filter：sysctl net.ipv4.conf.eth1.rp_filter=0或=2，不能是1 - 物理链路要独立：心跳网络建议双交换机主备，避免单点故障；万兆网卡配万兆交换机，千兆网卡别硬上9000 MTU
真正卡住延迟的，往往不是某个参数没设，而是某处链路静默丢包——比如交换机没开jumbo、网卡驱动没加载jumbo支持、或者LMS进程根本没读到新rmem_max值。这些点不逐个过一遍，改再多配置也白搭。
