根本原因是重负载导致cssd进程调度延迟，引发网络心跳超时（misscount）并触发投票驱逐，而非单纯心跳中断；其本质是资源争抢暴露了仲裁机制对时间敏感性的硬约束。
oracle rac 节点在重负载下出现脑裂，根本原因不是“负载高导致心跳断”，而是负载升高引发的**cssd 进程调度延迟 → 网络心跳超时（misscount）→ 触发投票驱逐**。这不是配置错误，而是资源争抢暴露了仲裁机制的时间敏感性。
为什么系统负载高会直接干扰 CSSD 心跳判断
CSSD（Cluster Synchronization Services Daemon）是 Oracle 集群的心跳核心进程，它必须在 misscount（默认 30 秒）内完成两次网络心跳收发 + 一次磁盘心跳写入。重负载下常见干扰包括：
- CPU 持续 100%：Linux 调度器无法及时唤醒
ocssd.bin，导致心跳包实际发出/接收延迟超过misscount - 内存换页严重（swapping）：
ocssd.bin的堆内存被 swap out，恢复时发生毫秒级卡顿，累积后突破超时阈值 - I/O 队列拥堵（特别是 voting disk 所在 ASM 磁盘组）：
clssnmCheckDskInfo写票失败或超时，CSSD 认为“磁盘心跳不可靠”，转而更依赖本已不稳的网络心跳 - 大页（HugePages）未启用或配置不足：
ocssd.bin内存分配失败后 fallback 到普通页，TLB miss 激增，加剧 CPU 开销
crsctl get css misscount 和 disktimeout 的配合陷阱
两个关键参数不是独立生效的，它们构成一个“时间窗口竞争”：
-
misscount是网络心跳容忍上限（如 30 秒），一旦连续未收到对方心跳即触发仲裁流程 -
disktimeout（默认 200 秒）是磁盘心跳失效判定阈值，但它只在仲裁启动后才起作用——也就是说，**节点先因网络超时进入“疑似脑裂”状态，再用磁盘心跳来决定谁活下来** - 问题在于：重负载下，
misscount很容易先被击穿；而此时若 voting disk I/O 延迟也因负载升高到 150ms+，disktimeout就失去兜底能力，节点只能按“旧投票记录”自裁
两节点集群在高负载下最危险的三个信号
这些日志和现象不是“已经脑裂”，而是“即将脑裂”的明确预警：
-
ocssd.log中反复出现clssnmWaitForAckstimeout 或clssnmSendSyncfailed —— 说明 CSSD 发心跳包都发不出去 -
crsctl stat res -t | grep ora.cluster_interconnect.haip显示资源状态在ONLINE/OFFLINE之间抖动 —— HAIP 底层网卡驱动已开始丢包或中断 -
top -p $(pgrep ocssd)显示%CPU持续 > 80%，且TIME+列每秒增长异常快 —— CSSD 进程本身正在被系统资源反噬
真正难处理的不是“怎么加资源”，而是负载波动时 misscount 和 disktimeout 的数值关系会动态失衡；很多 DBA 调大 misscount 后反而更易脑裂，因为这延长了“误判窗口”，让节点在 I/O 已不可靠时还硬撑着不投票。
