必须先运行oifcfg getif确认标记cluster_interconnect的接口，再用ip addr show核验状态，tcpdump抓6200端口包验证真实流量路径，而非依赖配置文件或ping测试。
确认真实心跳接口和流量路径
Oracle RAC不认配置文件里写的网卡，只认oifcfg getif输出中标记为cluster_interconnect的那个接口。很多DBA改完oifcfg setif就以为生效，结果没重启CRS，或者把public网卡误标为interconnect，导致GCS/ges流量实际走错路径。
实操建议：
- 先运行
oifcfg getif，确认输出中带cluster_interconnect标记的接口名（如enp0s9/10.10.10.0:cluster_interconnect） - 用
ip addr show enp0s9核对该接口是否UP、IP是否在预期子网、状态是否LOWER_UP - 在两个节点上同时执行
tcpdump -i enp0s9 -c 100 'host 10.10.10.2 and port 6200'，看是否有持续进出的TCP SYN/ACK包——这才是GCS真实通信路径 - 别用
ping测延迟：ICMP可能被QoS限速或走不同路由；改用hping3 -c 10 -p 6200 -S 10.10.10.2模拟GCS建连行为
验证并强制UDP小包走巨帧链路
MTU=9000 ≠ 延迟下降。必须端到端一致支持Jumbo Frame、UDP流量真实走巨帧、Oracle进程读取新缓冲区值三者齐备，漏一即白配。
实操建议：
- 用
ethtool eth1查Supports jumbo frames: Yes；若为No，换驱动或网卡（老版e1000e默认关jumbo） - 运行
ping -M do -s 8972 -I eth1 <remote_node>实测，失败说明链路层不支持 - 必须停集群统一设MTU：
crsctl stop crs→ip link set dev <private_if> mtu 9000→ 启动前跑cluvfy comp nodecon -n all -verbose - 抓包验证：
tshark -i eth1 -f "udp port 12560" -T fields -e frame.len | sort -u，出现8972或接近值才算成功；若全是1500左右，说明交换机端口未开jumbo
调大UDP接收缓冲区并重启LMS进程
gc cr block lost本质是OS内核UDP接收队列满后丢包，Oracle不重传，由上层重试兜底。这和net.core.rmem_max设置过小强相关。
实操建议：
- 查
netstat -su | grep "rcvbuferrors"，每秒增长>0即说明缓冲区太小 - 设为≥24M：
sysctl -w net.core.rmem_max=25165824，并写入/etc/sysctl.conf - 验证
cat /proc/sys/net/core/rmem_max是否生效 - 关键：LMS进程只在启动时读该值，调整后必须重启数据库实例，否则无效
排查交换机背板与中断分布瓶颈
万兆私网跑不满，90%以上是交换机背板带宽打满或UDP接收中断集中在单核所致。ifconfig显示“UP”不代表转发平面可用。
实操建议：
- 用
netperf -H <peer-ip> -t UDP_STREAM -l 60实测，单向吞吐低于7Gbps就要怀疑背板 - 查交换机CPU利用率：
display cpu-usage（华为）或show processes cpu（Cisco），持续>85%说明ASIC处理过载 - 查接收端中断分布：
cat /proc/interrupts | grep enp0s9，若所有中断集中在单个CPU核，说明RSS未生效，执行ethtool -X enp0s9 equal 4（按实际CPU数调整） - 禁用TSO/GSO：
ethtool -K enp0s9 tso off gso off，否则网卡会把小包强行聚合，掩盖真实小包处理能力不足
