第一反应是跑netstat -su | grep "rcvbuferrors"，若每秒增长>0，说明内核UDP接收缓冲区溢出，需立即将net.core.rmem_max设为≥24MB并重启Oracle实例生效。
查 netstat -su 里的 rcvbuferrors 是不是真瓶颈
看到 gc cr block lost 等等待上升，第一反应不该是调 oracle 参数，而是立刻跑 netstat -su | grep "rcvbuferrors"。这个值每秒增长 > 0，基本锁定为内核 udp 接收缓冲区溢出——rac 的 gcs/ges 流量走 udp，丢包后 oracle 不重传，只靠上层重试兜底，结果就是延迟飙升、块丢失。
默认 net.core.rmem_max 通常只有 212992 字节（约 208KB），完全不够。必须设到 ≥ 24M：sysctl -w net.core.rmem_max=25165824，并写入 /etc/sysctl.conf 持久化。
关键点：LMS 进程只在启动时读该值，改完不重启 Oracle 实例，等于没改。
- 验证是否生效：
cat /proc/sys/net/core/rmem_max输出必须是25165824 - 检查
packet reassembles failed是否同步下降——这是 MTU 不匹配的铁证 - 避免和
net.core.rmem_default混淆，Oracle 只认rmem_max
用 netperf 测 UDP_STREAM 看真实带宽上限
ifconfig 显示的 RX/TX 字节数含以太网头和 CRC，比 Oracle GC 载荷多 40–60 字节/包，直接除理论带宽会高估利用率 15%–20%。别信“才用了 30%”这种假象。
实测必须用 netperf 走真实协议栈：
- 测 TCP 吞吐：
netperf -H <peer-ip> -t TCP_STREAM -l 60</peer-ip> - 测 UDP 吞吐（更关键）：
netperf -H <peer-ip> -t UDP_STREAM -l 60</peer-ip> - 万兆私网稳定值应 ≥ 9 Gbps；低于 7 Gbps 就要查交换机背板、驱动或中断合并
注意：UDP 测试中若吞吐骤降或抖动大，优先看交换机 CPU 利用率（display cpu-usage 或 top -H），老款盒式交换机（如 Cisco 3750）背板常被低估。
确认私网两端 + 交换机 MTU 全部设为 9000
RAC GC 块大小常达 64K，MTU=1500 时必然分片。而分片重组失败（packet reassembles failed）不是偶发错误，是持续性丢包源头——OSWatcher 日志里这个指标一涨，就说明已有节点在静默丢包。
三端必须一致，漏一个就白配：
- Linux 节点：
ip link set dev eth1 mtu 9000（临时），或写进/etc/sysconfig/network-scripts/ifcfg-eth1的MTU=9000 - 华为交换机：
system jumboframe enable+interface GigabitEthernet X/X/X; jumboframe enable - Cisco：
system mtu routing 9000+interface TenGigabitEthernet X/X; mtu 9000
改完必须重启网卡或整机网络服务，且所有节点+交换机需一步到位。常见坑是交换机开了 Jumbo Frame，但某个节点忘了改 MTU，流量进来就丢。
别乱调 _gc_lms_processes，先看 GV$EVENT_HISTOGRAM 分桶
很多人一见 gc cr block busy 高，就加 _gc_lms_processes 到 4 或 6。但超过 4 容易引发 LMS 进程间竞争，反而推高 CPU 开销，得不偿失。
真正该先看的是 GV$EVENT_HISTOGRAM 中该事件的延迟分布：
- 如果集中在
1ms或4ms桶 → 大概率是锁争用或 SQL 访问模式问题，不是网络 - 如果突增在
16ms桶 → 才指向网络抖动、中断延迟或缓冲区溢出 - 配合
iftop -P tcp -f "port 6200 or port 6201"确认是不是某两个节点之间流量压倒性偏高
调整隐含参数前，务必用 10046 trace 抓 GC 密集会话，看 WAIT #1: nam='gc current block 2-way' 后面紧跟着的 SQL —— 往往是未绑定变量的循环 INSERT 或全表扫描 JOIN，这才是根因。
