Oracle 12c RAC在VMware中“假死”是因CSSD心跳卡住而非网络物理中断，表现为crsctl check cluster仍SUCCESS但业务不可用；根本原因是VMware资源争用（未设CPU/内存预留、启用Memory Hot Add、e1000e驱动等）导致CSSD线程调度延迟或UDP收包失败，使集群无法触发真实驱逐。
Oracle 12c RAC 在 VMware 中“假死”——不是进程挂了，而是 CSSD 心跳卡住、节点没驱逐但已失联，最典型表现是 crsctl check cluster 仍返回 SUCCESS，但客户端连不上 VIP、srvctl status service 显示服务异常、ocssd.log 里大量 “missed heartbeat” 却无节点重启。
为什么 VMware 下容易出现“假死”而非真驱逐
真实驱逐需要 CSSD 连续错过 misscount × missinterval（默认 30 秒）的心跳包，但 VMware 环境下常卡在“半死”状态：网卡 ethtool eth0 显示 Link detected: yes，CSSD 认为链路正常，却因 CPU 抢占、内存气球回收或虚拟网卡驱动延迟，收不到远端 UDP 心跳包。此时集群状态未降级，VIP 不漂移，服务不 failover，但业务已中断。
常见诱因包括：
- VMware 虚拟机未设置 CPU / 内存
Reservation，宿主机资源争用时 CSSD 线程被调度延迟超过 500ms - 启用了
Memory Hot Add，干扰 Linux NUMA 绑定，导致 ASM 实例无法稳定访问本地内存节点 - 私网使用
e1000e驱动而非vmxnet3，UDP 小包处理效率低，gc cr block busy等待事件飙升 - ESXi 主机 BIOS 中未启用 Intel VT-x/EPT，Cache Fusion 流量被迫走软件模拟，CPU 使用率持续 >90%
如何确认是不是 CSSD 心跳卡住而非网络物理中断
别只看 ifconfig 或 ip link show ——它们只反映链路层状态。关键要看 CSSD 是否实际收到了心跳：
- 查
$GRID_HOME/log/<hostname>/cssd/ocssd.log，搜索missed heartbeat，注意时间戳是否密集连续（如每秒一条），而非偶发 - 执行
crsctl get node role，若返回hub但olsnodes -s显示另一节点为unreachable，说明角色同步已断 - 运行
strace -p $(pgrep ocssd) -e trace=recvfrom,sendto -s 1024 -o /tmp/cssd_net.log，观察是否有 recvfrom 调用长时间阻塞或超时 - 对比
date; cat /proc/net/udp | grep :3075（默认 CSSD 端口），看rx_queue值是否持续 >1000，表明内核接收队列堆积
VMware 侧必须检查的三项配置
这些配置错误不会报错，但会让 RAC 在高负载下进入“亚健康”状态：
-
CPU Reservation = CPU Count且Memory Reservation = Memory Size（例如 8 vCPU / 16GB → 预留也设为 8 / 16），禁用所有“限制”和“份额”策略 - 虚拟机设置中关闭
Memory Hot Add，并在 RHEL 侧验证：cat /sys/devices/system/node/node*/meminfo | grep MemTotal，确保各 NUMA 节点内存值稳定不跳变 - 私网网卡驱动强制设为
vmxnet3，并在 ESXi 主机上启用Net.TcpipHeapMax（建议值134217728）以扩大 TCP/IP 栈缓冲区
快速验证与临时缓解手段
假死发生后，不要立刻 reboot —— 先尝试定位和缓解：
- 在疑似卡住节点执行：
crsctl stop res ora.cssd -f && crsctl start res ora.cssd，观察是否能重建心跳（比整机重启快 3 分钟） - 临时提升 CSSD 超时容忍度：
crsctl set css votedisktimeout 60（仅限紧急恢复，非长期方案） - 检查 VMware Tools 版本，必须 ≥11.3.5；旧版存在
vmtoolsd与ocssd争抢 CPU 的已知 Bug - 若使用共享存储，确认
disk.EnableUUID="TRUE"已写入 .vmx 文件 —— UUID 错乱会导致 ASM disk discovery 失败，间接拖慢 CSSD 初始化
真正棘手的是那些没有明显日志报错、crsctl check cluster 一切正常的“静默卡顿”，往往要结合 ESXi 主机的 esxtop（看 %RDY 和 %MLMTD）与 RAC 节点的 top -H -p $(pgrep ocssd)（看单线程 CPU 占用）交叉比对才能揪出根因。
