rx_pause_cnt持续上涨说明交换机正对RAC私网端口发送PAUSE帧实施流控，属底层网络限速，非Oracle或OS问题；需检查交换机buffer配置、禁用流控，并统一MTU、双工模式。
ethtool -S 查到 rx_pause_cnt 持续上涨，说明交换机在发流控帧
只要 ethtool -s eth2 | grep -i rx_pause_cnt 输出值每秒增长，基本可判定交换机正对 rac 私网端口施加流量控制（pause 帧），这不是 oracle 或 os 的问题，而是底层网络主动限速。rac 私网流量突发性强，lms 进程发包节奏快，一旦交换机 buffer 不足，就会触发 pause 帧让网卡暂停收包——结果就是驱动层静默丢包，ifconfig 里的 dropped 字段会同步上涨，但 errors 通常为 0。
常见诱因包括：
- 交换机端口未配置足够 buffer，尤其在多节点同时 GC 流量激增时
- 私网使用共享交换机而非专用无阻塞交换机
- 交换机 QoS 策略误将 UDP 流量标记为低优先级并限速
为什么禁用网卡 LRO/GRO 能缓解丢包
RAC 私网心跳和 GC 流量依赖精确的包边界与时序，而 ethtool -K eth2 lro off gro off 是必须项。LRO（Large Receive Offload）和 GRO（Generic Receive Offload）会在驱动层把多个小包合并成一个大包再往上送，导致：
- ksxp 消息解析错乱，心跳包被延迟或吞并
- UDP 接收队列中单个“逻辑包”过大，加剧
UdpInOverflows - 与 HAIP 的 ARP 响应节奏不匹配，引发偶发性
CRS-1611
注意：lro 和 gro 默认在多数厂商网卡上是开启的，必须显式关闭，且需在所有节点统一执行。
交换机端口配置必须匹配：MTU、流控、双工模式
RAC 私网要求两端（服务器网卡 + 交换机端口）配置严格一致，任何一项不匹配都会引发隐性丢包：
-
MTU：必须全链路统一为 9000（巨帧），验证命令是ping -M do -s 8972 node2-priv；若返回Frag needed and DF set (mtu = X)，说明某处仍为 1500 - 流控：
ethtool -a eth2查看当前状态，生产环境建议交换机侧禁用 PAUSE 帧（rx off tx off），服务器侧保持rx off tx off - 双工模式：必须强制设为
10000baseT/Full，禁止 auto-negotiation，避免协商失败后降为半双工引发冲突丢包
别只盯 netstat -su，先确认 UdpInOverflows 是不是真源头
netstat -su | grep "UdpInOverflows" 非零确实指向 UDP 接收缓冲区溢出，但这个现象往往是结果而非根因。如果 rx_pause_cnt 已在涨，那 UdpInOverflows 就是流控导致的连锁反应——网卡被暂停收包，OS 队列空转，新包一来就满，直接丢弃。
此时调大 net.core.rmem_max 只能延缓症状，无法阻止丢包。真正要做的顺序是：
- 先用
ethtool -S确认硬件级丢包来源 - 再检查交换机 buffer 和流控配置
- 最后才调整 OS 参数，并确保 Oracle 实例重启以加载新
rmem_max
HAIP 地址是否通、ocssd.log 里 CRS-1611 出现频率、以及 GV$SYSTEM_EVENT 中 gc cr block lost 是否同步飙升，这三者必须交叉比对，才能排除误判。
