最直接的oracle rac心跳丢包证据是ocssd.log中的crs-1611/1610/1607错误，三者呈递进关系：crs-1611表75%心跳丢失，crs-1610表90%丢失，crs-1607触发节点驱逐；多节点同时报错指向网络抖动，单点报错优先查本机网卡、驱动或rp_filter。
直接查 ocssd.log 里的 CRS-1611/1610/1607 错误
Oracle RAC 心跳丢包最直接的证据不在 ping 或 netstat，而在每个节点的 /oracle/11.2.0/grid/log/<hostname>/cssd/ocssd.log</hostname>。别翻几百兆日志，用 grep -i "crs-1611\|crs-1610\|crs-1607" ocssd.log 即可定位。
这三类错误是递进关系，不是孤立出现：
-
CRS-1611表示 75% 心跳丢失，后面带的时间值（如in 6.512 seconds）越小，说明恢复窗口越窄，抖动越剧烈 -
CRS-1610是 90% 丢失，通常紧随其后；若只有一侧报这个，另一侧没对应记录，大概率是本端收包异常（比如网卡中断风暴），不是对端问题 -
CRS-1607是驱逐触发点，一旦密集出现，基本已发生节点踢出
关键判断：多个节点在同一时间窗口内都打出这些错误，才指向底层网络抖动；单点报错优先查本机网卡、驱动或 rp_filter 设置。
用 ethtool -S 看网卡底层丢包计数
crsctl check cluster -all 只能告诉你“集群通不通”，不能区分是网络抖动还是上层阻塞。真要定位抖动，必须下到网卡驱动层。
执行：ethtool -S eth1 | grep -E "(rx_discards|tx_aborted_errors|rx_errors|rx_fifo_errors)"
只要输出非零，就说明问题在物理链路或驱动层面：
-
rx_discards高 → ring buffer 溢出，可能 CPU 调度跟不上或中断绑定不合理 -
rx_errors或rx_crc_errors高 → 网线、模块、交换机端口物理层异常（CRC 错误基本等于换线） -
tx_aborted_errors高 → 交换机限速、QoS 丢包，或双工模式不匹配（务必确认两端都是全双工）
注意：ifconfig eth1 显示的 RX/TX 字节数不能直接除以带宽算利用率——它统计的是含以太网头的 L2 字节数，而 Oracle GC 流量走 TCP 载荷，每包多出 40–60 字节，直接套用会高估 15%–20%。
用 ping -c 100 -i 0.1 测私网延迟分布
RAC 私网对延迟敏感度远高于丢包率。跑 ping -c 100 -i 0.1 ，重点不是看平均延迟，而是看分布：
- 95% 的包延迟 ≤ 2ms 是健康基线
- 一旦 >5% 的包超过 5ms，
gc cr block lost等等待事件就会明显上扬 - 如果出现大量 >10ms 的毛刺，且和
ocssd.log中 CRS-1611 时间戳吻合，基本锁定抖动源
更准的指标其实是 GV$SYSTEM_EVENT 中的 GC 等待桶分布——比如 gc cr block 2-way 等待时间集中在 5–10ms 区间，比 ping 值更能反映真实 GC 包处理延迟。
查 netstat -s 看 IP 层重组失败
心跳包走 UDP，但底层是 IP 分片传输。当网卡 MTU 不一致（比如一端 1500、一端 9000），或内核重组缓冲区过小，会导致静默丢包——ping 和 ethtool 都看不出异常，但 netstat -s 会暴露。
重点关注这几行：
-
packets reassembled ok—— 成功重组数 -
packet reassembles failed—— 失败数（这个值持续增长就是典型症状） -
fragments received ok/fragments created—— 对比看是否大量分片
若 packet reassembles failed 高，需调大内核参数：net.ipv4.ipfrag_high_thresh（建议设为 41943040）、net.ipv4.ipfrag_low_thresh（设为 40894464）、net.ipv4.ipfrag_time（设为 120）。改完必须 sysctl -p 生效，且重启 CSSD 进程才能清空旧缓冲区。
真正麻烦的不是丢包本身，而是丢包发生在哪一层：网卡驱动丢的、IP 层重组失败的、还是 UDP socket 缓冲区溢出的——每一层对应的排查工具和修复动作完全不同。别一上来就换网线或调 MTU，先让 ocssd.log 和 netstat -s 说话。
