私网延迟剧增90%以上是交换机背板带宽打满或UDP接收缓冲区溢出所致，应优先检查netstat -su的rcvbuferrors和packet reassembles failed指标，而非依赖AWR等待事件。
私网延迟剧增不是数据库问题，90%以上是交换机背板带宽打满或udp接收缓冲区溢出导致的。直接看 netstat -su 的 rcvbuferrors 和 packet reassembles failed 这两个指标，比查 awr 等待事件更快定位根因。
怎么看是不是交换机背板带宽瓶颈
万兆私网不等于节点间能跑满 10Gbps——中间交换机背板带宽可能只有 2G 或 4G，尤其老型号盒式交换机（如 Cisco 3750、华为 S5700 系列早期款）背板带宽常被低估：
- 用
netperf -H <peer-ip> -t UDP_STREAM -l 60</peer-ip>在两个 RAC 节点间实测：单向持续吞吐低于 7 Gbps 就要怀疑背板 - 登录交换机查
display interface brief（华为）或show interfaces status（Cisco），确认端口协商速率是 10G 且无input/output errors、discards - 重点查交换机 CPU 利用率：
display cpu-usage持续 > 85%，说明包转发已过载，背板或 ASIC 处理能力不足 - 不要只信“端口 UP”：物理链路通 ≠ 转发平面可用。RAC 私网流量突发性强，背板拥塞时会静默丢包，
ifconfig完全不体现
为什么 gc cr block lost 直接指向 UDP 协议栈
RAC 的 GCS/GES 流量默认走 UDP，Oracle 不重传丢失的数据包，由上层重试机制兜底——所以 gc cr block lost 出现，本质是 OS 内核 UDP 接收队列满了，新包被直接丢弃：
-
netstat -su | grep "rcvbuferrors"每秒增长 > 0，说明net.core.rmem_max设置过小（默认通常 212992 字节） - 必须调大到 ≥ 24M：
sysctl -w net.core.rmem_max=25165824，并写入/etc/sysctl.conf - 改完必须验证：
cat /proc/sys/net/core/rmem_max输出是否为 25165824 - 关键：Oracle LMS 进程只在启动时读取该值，
rmem_max调整后必须重启数据库实例才生效
MTU 不匹配如何引发延迟和丢包
私网两端、交换机三者 MTU 不一致（比如节点设了 9000，交换机仍是默认 1500），会导致大量 IP 分片，而 RAC 的 GC 块大小常达 64K，分片后重组失败概率飙升：
-
netstat -s | grep "reassembles failed"持续上升，就是 MTU 不匹配的铁证 - Linux 上查当前 MTU：
ip link show dev eth1 | grep mtu - 交换机侧必须同步开启 Jumbo Frame：
system jumbo-frame enable（华为）或system mtu routing 9000（Cisco） - 注意：修改 MTU 后需重启网卡或整个网络服务，且必须所有节点+交换机一步到位，漏一个就白调
真正卡住排查的，往往不是参数没调，而是调了没生效、改了没重启、配了没同步。比如 rmem_max 改了但忘了重启 Oracle 实例，或者交换机开了 Jumbo Frame 但某个节点网卡仍用默认 MTU——这些细节不验，所有分析都停在表层。
