Oracle RAC Interconnect实际生效的是oifcfg getif中标记cluster_interconnect的接口，需用tcpdump和hping3验证真实路径及延迟，而非仅依赖ping或iperf3单流测试。
Interconnect网络延迟高，oifcfg查到的网卡真正在用吗？
oracle rac的interconnect不是靠配置文件“写出来”就生效的，而是由oifcfg getif输出中带cluster_interconnect标记的接口实际承载。常见错误是：dba改了oifcfg setif但没重启crs，或误把public网卡当interconnect用——这时ping -c 5 <other-node-interconnect-ip></other-node-interconnect-ip>测出的延迟根本不能反映真实rac通信路径。
实操建议：
- 先运行
oifcfg getif确认当前生效的interconnect接口，再用ip addr show <ifname></ifname>核对该接口是否UP且IP配置正确 - 在两个节点上同时执行
tcpdump -i <ifname> -c 100 'host <peer-interconnect-ip> and port 6200'</peer-interconnect-ip></ifname>（6200是默认GCS/GES端口），确认心跳包真从该网卡进出 - 避免用
ping测延迟——ICMP可能走不同路由或被QoS限速；改用hping3 -c 10 -p 6200 -S <peer-ip></peer-ip>模拟TCP SYN包更贴近真实场景
用iperf3测吞吐时，为什么单流结果远高于RAC实际表现？
iperf3默认单TCP流测的是网卡和链路理论上限，但RAC的Global Cache Service（GCS）使用大量短小、随机的UDP包（如block pin/unpin、SCN同步），受MTU、中断合并（IRQ coalescing）、网卡RSS队列分布影响极大。
实操建议：
- 模拟真实负载：用
iperf3 -u -b 0 -l 128 -P 32（UDP、不限速、128字节包、32并发流），128B接近Oracle block request头大小 - 检查接收侧中断分布：
cat /proc/interrupts | grep <nic-name></nic-name>，若所有中断集中在一个CPU核，说明RSS未生效，需调ethtool -X <ifname> equal <n></n></ifname> - 禁用网卡TSO/GSO：
ethtool -K <ifname> tso off gso off</ifname>，否则大包分片会掩盖小包处理瓶颈
crsctl stat res -t里ora.cluster_interconnect.haip资源异常，但网络连通性正常？
HAIP（Highly Available IP）是Oracle 11.2+为Interconnect自动漂移设计的虚拟IP，它不依赖OS层bonding或keepalived。即使物理链路up，HAIP资源offline往往意味着底层UDP多播通信失败——而多播问题在交换机端最常被忽略。
实操建议：
- 检查交换机IGMP Snooping是否启用：若启用但未配置querier，HAIP多播注册会超时；临时关闭IGMP Snooping可快速验证
- 抓包确认多播收发：
tcpdump -i <ifname> 'multicast and port 42424'</ifname>（Oracle默认多播端口），一端发包另一端收不到即为多播断点 - 绕过HAIP直测：在
/etc/hosts中静态绑定对方节点的HAIP地址到物理IP，再运行oifcfg getif看是否识别为interconnect——这能排除DNS或GNS干扰
AWR报告里gc cr block receive time和gc current block receive time飙升，但网络测试一切正常？
这两个指标反映的是“块请求发出到本地缓存收到”的端到端耗时，包含网络传输+远程节点CPU排队+本地LMS进程调度。网络通畅≠无瓶颈——LMS进程被高负载压住、或远程节点SGA中buffer busy waits堆积，都会拖慢GC响应。
实操建议：
- 查远程节点
v$session_wait中等待gcs log flush或gc cr grant 2-way的会话，确认是否LMS写redo日志慢（如log file sync高） - 对比
v$sysstat中global cache cr blocks served与global cache cr blocks received比值，若显著低于1，说明请求方丢包或重传（需查netstat -s | grep -i "reasm"） - 在高负载时段采样
top -H -p $(pgrep -f 'ora_lms') -b -n 1，观察LMS线程CPU占用是否持续超80%，超则需调_lm_cache_size或增加LMS进程数（_lms_processes）
Interconnect瓶颈从来不在单一环节：交换机ACL规则可能静默丢弃UDP包，网卡驱动bug会导致特定包长校验失败，甚至BIOS中C-states节能设置会让中断响应延迟突增到毫秒级——这些都得逐层排除，不能只信iperf3数字。
