应通过iftop实时观察节点对间UDP流量分布并结合gv$sysstat中各节点gc blocks received/served值对比来判断偏斜，因AWR“Interconnect Traffic per Second”为估算值且混杂非GC流量，GV$CLUSTER_INTERCONNECTS不记录字节计数，GV$INTERCONNECT_PINGS测的是ICMP延迟而非真实GC传输耗时。
怎么看 RAC 节点间 GC 流量是否偏斜
awr 报告里的 “interconnect traffic per second” 表格只给估算值，不能直接用来判断负载是否均衡。它基于平均块大小（默认 8kb）× 块数算出，但真实 udp 包含 ip/udp/以太网头，线缆字节数高 15%–20%，且不区分 gc 流量和 cssd 心跳、ocr 同步等其他私网通信。
真正要盯的，是节点对之间的实时流量分布——GC 流量从来不是均匀打散的，往往集中在某一对（比如 node1 ↔ node3），而 node2 和 node4 几乎空闲。这种偏斜会导致单链路拥塞、GC 延迟毛刺、甚至触发 gc current block busy 等等待事件。
实操建议：
- 用
iftop -P udp -f "host 169.254.x.x and host 169.254.y.y"在每个节点上实时观察双向流量，重点关注发送/接收速率是否严重偏离均值（比如某节点发送量是其他节点的 3 倍以上） - 别只看总量：运行
SELECT inst_id, name, value FROM gv$sysstat WHERE name IN ('gc cr blocks received','gc current blocks received','gc cr blocks served','gc current blocks served') ORDER BY inst_id, name;，对比各节点received总和 vsserved总和——理想情况下应大致守恒；若某节点received显著 >served，说明它在被动拉数据，可能本地资源不足或 SQL 绑定不均 - 标准差比平均值更有意义：4 节点的
gc cr blocks received若为100k / 95k / 110k / 20k，第 4 节点就是异常点，不是看“整体平稳”
为什么 GV$CLUSTER_INTERCONNECTS 不反映真实流量
GV$CLUSTER_INTERCONNECTS 只告诉你 Oracle 声明用了哪张网卡（比如 bond1），但它不记录任何字节计数，也不带时间戳，更无法区分 GC 流量和 CSSD、CRSD、OCR 同步等其他私网通信。很多人查到它返回了 eth2 就以为“走这张卡”，结果抓包发现 GC 全在 bond1 上跑——因为实际路由策略、HAIP 绑定、内核 bonding 模式都可能绕过声明配置。
实操建议：
- 不要依赖该视图做容量规划或故障定位
- 确认 HAIP 地址：
oifcfg getif或ip addr show查169.254.x.x/16段地址，这才是 GC 流量的真实源/目标 IP - 检查 bonding 状态：
cat /proc/net/bonding/bond1看 active slave 和 link status，避免物理链路降级却未被数据库感知
怎么用 tcpdump 抓准 GC UDP 包
RAC 11.2.0.2+ 默认走 HAIP（169.254.x.x）和动态 UDP 端口（非 1521），直接抓静态私网 IP 或监听端口会一无所获。漏掉反向包还会导致流量低估 40% 以上。
实操建议：
- 命令必须同时满足三个条件：
tcpdump -i bond1 -n udp and host 169.254.23.37 and host 169.254.23.38 -w gc_udp.pcap -
-n必须加：避免 DNS 反查拖慢捕获，也防止时间戳被干扰 - 不能用
port 1521：GC 不走监听端口；也不要用portrange宽泛过滤——会混入 NTP、DHCP 等噪音 - 必须写两个
host：只写单向会漏 ACK 或响应包，Wireshark 打开后用udp.length > 100过滤，GC 包一般 ≥ 128 字节
为什么 GV$INTERCONNECT_PINGS 是伪指标
GV$INTERCONNECT_PINGS 测的是 ICMP ping 延迟，不是 GC 包实际传输耗时。它默认每 5 秒发一次，完全跟不上业务毛刺；而且 ping 走的是内核 ICMP 栈，GC 走的是 Oracle 用户态 UDP 栈，路径不同、优先级不同、甚至可能被不同队列调度。
实操建议：
- 别拿它当 GC 延迟依据，尤其在出现
gc cr block 2-way等等待时 - 真要看延迟：用
tcpdump抓包后，在 Wireshark 里看 UDP 包的 delta time（需开启 relative time），或用perf跟踪sendto/recvfrom系统调用耗时 - 结合
ethtool -S bond1查rx_dropped、tx_dropped，驱动层丢包才是 GC 延迟的硬瓶颈
