高峰期节点驱逐主因是私网流量激增叠加内存压力导致cssd调度延迟、本地心跳失效，并非网络丢包；关键证据是ocssd.log中出现“node eviction initiated”，而非仅“missed heartbeat”。
高峰期节点驱逐不是网络丢包本身导致的，而是私网流量激增叠加内存压力后，cssd 进程调度延迟，造成本地心跳失效——其他节点看到的是“失联”，实际是本节点已卡死。
查 ocssd.log 里有没有 node eviction initiated 而不是 missed heartbeat
看到 missed heartbeat from node X 只是预警，不等于驱逐已发生；真正触发点是日志中明确出现 node eviction initiated。高峰期大量该告警但无 initiated，说明只是抖动；若紧跟着出现该标记，且时间点与业务峰值重合，就要怀疑本节点 cssd 自身异常。
常见误判：
- 只 grep
missed heartbeat就断定是网络问题，忽略后续是否真进入驱逐流程 - 在远端节点日志查到告警，却没去被驱逐节点的
$GRID_HOME/log/<host>/cssd/ocssd.log看本地 cssd 是否卡住 - 用
cluvfy comp nodecon -n all测试时网络正常，但没复现高峰期私网满载下的真实延迟
用 iostat -x 1 和 free -g 同步看磁盘 I/O 与内存水位
高峰期私网流量上涨常伴随 ASM IO 压力上升（如大量归档写、RMAN 备份），voting disk 所在磁盘组若 %util > 95 或 await > 50ms，会导致磁盘心跳响应超时——即使 disktimeout 设为 200 秒，持续高延迟也会让 cssd 判定“磁盘心跳不可靠”，转而更依赖网络心跳，放大私网波动影响。
同时检查内存：
-
free -g显示available< 4GB（或低于总内存 10%）时，内核可能开始 swap，cssd 进程因 real-time 优先级反而更易被饿死 -
dmesg -T | grep -i "killed process"查是否有ocssd.bin或oracle进程被 OOM Killer 终止 -
ps -eo pid,comm,pcpu,pmem,rtprio --sort=-pcpu | head -10看 cssd 是否长期处于 0% CPU 占用（卡死）或反复被抢占
验证私网是否真丢包，还是只是延迟毛刺
高峰期私网 ping 延迟从 0.2ms 涨到 8ms 不代表丢包，但足以让 cssd 的本地心跳检测失败——因为 cssd 默认每秒发一次心跳，超时判定基于 misscount（默认 30 秒），但内部采样窗口极短，连续几毫秒调度延迟就可能漏检。
实操建议：
- 不用
ping，改用crsctl check ctss和crsctl check css直接测集群服务层连通性 - 在私网接口上抓包：
tcpdump -i bond1 -c 1000 'host <other_private_ip> and port 12345' -w /tmp/cssd.pcap（Oracle 12c 默认 cssd 端口是 12345） - 重点看 timestamp 差值：若包发出后 10ms 才收到应答，且该现象在驱逐前 2 分钟集中出现，就是典型调度延迟，不是链路中断
为什么调大 misscount 反而让问题更隐蔽
盲目把 misscount 从 30 改成 60，看似延长容忍窗口，实则掩盖了 cssd 卡死这个根本问题。节点在 “失联” 状态下继续运行 30 秒，期间可能已产生脏数据、锁堆积、LMON hang，最终驱逐时代价更大。
真正该做的是：
- 确认
disktimeout>misscount（必须，否则磁盘心跳永远来不及响应） - 关闭
oprocd（12c+ 默认禁用，若启用则强制退出） - 设置
vm.min_free_kbytes至至少物理内存的 3%（如 128G 内存设为 4194304），防止内核过度回收 page cache 导致 cssd 内存分配失败 - 检查是否启用了
hugepages：未启用时，高峰期大量小页分配竞争会直接拖慢 cssd 的 mmap 调用
复杂点在于：驱逐日志里几乎不体现内存调度问题，它只报“失联”。你得把 ocssd.log 时间戳、dmesg、iostat 输出和应用负载曲线对齐，才能看出 cssd 是在内存水位越过阈值那一刻开始掉心跳的。
