私网带宽不足是RAC实例间数据同步延迟最常见、易被误判为数据库问题的底层原因，表现为gc cr block busy等等待事件升高，需通过netstat、netperf等工具检测吞吐、丢包及MTU匹配性。
私网带宽不足是rac实例间数据同步延迟最常见、最容易被误判为“数据库问题”的底层原因。它不会直接报错，但会表现为 gc cr block busy、gc buffer busy acquire、gc block lost 等等待事件持续升高，且与业务并发量强相关。
怎么看私网实际吞吐和丢包
别只看 ifconfig 显示的“UP”状态——那只是链路层通了。真正要看的是传输层是否扛得住 Cache Fusion 的突发流量：
- 用
netstat -s | grep -i "retransmit\|drop"查 TCP 重传和 UDP 丢包（RAC 的 GCS/GES 主要用 UDP） - 运行
netperf -H -t TCP_STREAM -l 60测单向 TCP 吞吐，再用-t UDP_STREAM测 UDP；万兆私网应稳定在 9+ Gbps，低于 7 Gbps 就要警惕 - 检查 OSWatcher 的
netstat日志里packet reassembles failed是否增长——这是 MTU 不匹配导致分片重组失败的明确信号
为什么万兆网卡跑不满？重点查这三处
硬件标称万兆 ≠ 实际可用带宽。瓶颈常出在中间环节：
- 交换机端口是否启用 Jumbo Frame（MTU ≥ 9000）？私网两端和交换机必须一致，否则大量小包 → 高中断 + 丢包
- 网卡驱动是否为最新版？老版本
ixgbe或mlx5_core在高并发下存在 TX/RX 队列饥饿问题 - 是否启用了中断合并（
ethtool -c）？默认关闭时，每包中断一次，CPU 软中断飙升会拖慢 LGWR 和 LMS 进程处理速度
确认是带宽问题还是延迟问题？看这两个指标
网络延迟（ping）低 ≠ 私网同步快。Cache Fusion 对带宽更敏感，对单次延迟容忍度略高：
- 如果
ping -c 100平均延迟 gc cr block build time 指标 > 5ms，基本可锁定为带宽打满或缓冲区溢出 - 如果
netstat -su显示rcvbuferrors持续增长，说明内核 UDP 接收缓冲区（net.core.rmem_max）太小，需调大至 24M+ 并重启 Oracle（LMS 进程启动时读取） - 注意：调整
rmem_max后必须验证cat /proc/sys/net/core/rmem_max生效，且 Oracle 进程需重启才能使用新值
私网不是“配通就行”的基础设施，它是 RAC 全局缓存的生命线。很多团队花几天调 SQL 或参数，却没花十分钟跑一次 netperf ——结果所有优化都浮在水面上。
