Oracle 11g RAC压力测试响应变慢90%以上源于私网交换机背板带宽打满或UDP接收缓冲区溢出；应优先用netstat -su查rcvbuferrors和packet reassembles failed，而非依赖AWR，并通过netperf实测吞吐、查交换机端口状态与CPU利用率、统一调大rmem_max至24M且重启实例、同步配置Jumbo Frame来根治。
oracle 11g rac 在压力测试下响应变慢，90% 以上不是数据库本身的问题，而是私网交换机背板带宽打满或 udp 协议栈丢包导致的——直接看 netstat -su 的 rcvbuferrors 和 packet reassembles failed 就能快速确认，比翻 awr 报告快得多。
怎么验证交换机背板带宽是否真成瓶颈
万兆网口 UP ≠ 节点间能跑满 10Gbps。老型号盒式交换机（如 Cisco 3750、华为 S5700 早期款）背板带宽常被严重低估，实测才是唯一依据：
- 在两个 RAC 节点间运行
netperf -H <peer-ip> -t UDP_STREAM -l 60</peer-ip>，单向持续吞吐低于 7 Gbps 就该怀疑背板 - 登录交换机查端口状态：
display interface brief（华为）或show interfaces status（Cisco），确认端口协商速率为 10G 且无input errors/output discards - 查交换机 CPU 利用率：
display cpu-usage持续 > 85%，说明 ASIC 或转发引擎已过载，背板或处理能力不足 - 别信“物理链路通”：RAC 私网流量突发性强，背板拥塞时静默丢包，
ifconfig完全不体现
为什么 gc cr block lost 直接指向 UDP 接收缓冲区
RAC 的 GCS/GES 流量默认走 UDP，Oracle 不重传丢失的数据包，由上层重试兜底。所以出现 gc cr block lost，本质是内核 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 - 关键点：
LMS进程只在数据库启动时读取该值，rmem_max调整后必须重启 Oracle 实例才生效
MTU 不一致如何引发延迟和分片失败
RAC GC 块大小常达 64K，若私网两端、交换机三者 MTU 不一致（比如节点设了 9000，交换机仍是默认 1500），就会强制 IP 分片，而分片重组失败概率飙升：
- 交换机侧必须同步开启 Jumbo Frame：
system jumboframe enable（华为）或system mtu routing 9000（Cisco） - 修改 MTU 后需重启网卡或整个网络服务，且必须所有节点 + 交换机一步到位，漏一个就白调
- 检查各节点实际 MTU：
ip link show <iface> | grep mtu</iface>；检查交换机当前 MTU：display interface <port></port>（华为）或show interfaces <port></port>（Cisco）
真正卡住排查的，往往不是参数没调，而是调了没生效、改了没重启、配了没同步——比如 rmem_max 改了但忘了重启 Oracle 实例，或者交换机开了 Jumbo Frame，但某个节点网卡 MTU 还是 1500。
