1、案例概述

驻场同事的一套3节点RAC，前几天晚上，节点3的集群突然重启了。向同事大概了解这套环境的基本情况：这套RAC环境一直运行稳定，没怎么出过故障，半个月前，在节点3上部署了一套GoldenGate环境，进行全库数据的抽取，然后运行了半个月左右就出现节点3 的集群重启了。听到这一描述，我的最初反应就是节点3的GoldenGate是吃内存大户，肯定是它导致物理内存耗尽，最终swapin/swapout页操作，整个操作系统运行极其缓慢，最终集群重启。

2、案例分析

2.1 虽然心里已经有了初步结论，但还是让同事收集了三个计算节点的TFA日志。先看操作系统日志。故障出现在23:58左右，但在故障之前，三个计算节点的message日志没有任何异常。这大致排除了操作系统自身的硬件和内核问题。

2.2 查看三个计算节点的集群日志。

节点1的集群日志：

2026-09-05 23:58:10.181 [OCSSD(367469)]CRS-7503: The Oracle Grid Infrastructure process 'ocssd' observed communication issues between node 'xcdb01' and node 'xcdb03', interface list of local node 'xcdb01' is '192.168.10.101:14969;192.168.40.101:18962;', interface list of remote node 'xcdb03' is '192.168.10.105:47062;192.168.40.105:24036;'.
2026-09-05 23:58:16.996 [OCSSD(367469)]CRS-1612: Network communication with node xcdb03 (3) has been missing for 50% of the timeout interval.  If this persists, removal of this node from cluster will occur in 14.280 seconds
2026-09-05 23:58:23.997 [OCSSD(367469)]CRS-1611: Network communication with node xcdb03 (3) has been missing for 75% of the timeout interval.  If this persists, removal of this node from cluster will occur in 7.280 seconds
2026-09-05 23:58:28.998 [OCSSD(367469)]CRS-1610: Network communication with node xcdb03 (3) has been missing for 90% of the timeout interval.  If this persists, removal of this node from cluster will occur in 2.280 seconds
2026-09-05 23:58:31.781 [OCSSD(367469)]CRS-1607: Node xcdb03 is being evicted in cluster incarnation 577638101; details at (:CSSNM00007:) in /u01/app/grid/diag/crs/xcdb01/crs/trace/ocssd.trc.
2026-09-05 23:58:59.824 [OCSSD(367469)]CRS-1601: CSSD Reconfiguration complete. Active nodes are xcdb01 xcdb02 .
2026-09-05 23:59:10.349 [OCSSD(367469)]CRS-1601: CSSD Reconfiguration complete. Active nodes are xcdb01 xcdb02 xcdb03 .

节点2和节点3的集群日志与上述内容类似。从集群日志可以看出，节点3无法与节点和节点2之间进行网络通信。最终，节点3集群被驱逐。

至此，我们清楚节点3的集群为什么会重启了，是因为节点3与其他两个节点的网络通信出现了问题。那么，这是不是就表明网络层面出现了问题呢？很多人看到上面提及的日志，就以为是网络出了故障，其实恰恰相反，这个所谓的“网络故障”只是引发的后果。而真正的故障可能在其他方面。

2.3 继续查看ASM日志。节点1和节点2的日志无异常信息，而节点3的ASM日志如下所示：

2026-09-05T18:52:37.234084+08:00
Warning: VKTM detected a forward time drift. 
Please see the VKTM trace file for more details:
/u01/app/grid/diag/asm/+asm/+ASM3/trace/+ASM3_vktm_106574.trc
2026-09-05T20:15:52.276434+08:00
Warning: VKTM detected a forward time drift. 
Please see the VKTM trace file for more details:
/u01/app/grid/diag/asm/+asm/+ASM3/trace/+ASM3_vktm_106574.trc
2026-09-05T21:22:47.993541+08:00
Warning: VKTM detected a forward time drift. 
Please see the VKTM trace file for more details:
/u01/app/grid/diag/asm/+asm/+ASM3/trace/+ASM3_vktm_106574.trc
2026-09-05T22:51:47.342029+08:00
Warning: VKTM detected a forward time drift. 
Please see the VKTM trace file for more details:
/u01/app/grid/diag/asm/+asm/+ASM3/trace/+ASM3_vktm_106574.trc
2026-09-05T23:58:44.066362+08:00
NOTE: ASMB process exiting, either shutdown is in progress or foreground connected to ASMB was killed.
NOTE: ASMB clearing idle groups before exit

在节点3的集群重启之前 ，节点3的ASM日志中就多次出现Warning: VKTM detected a forward time drift. 

2.4 分析OSW日志。在TFA中找了半天，也没找到OSW日志，后来询问才得知，这套环境的OSW早就关闭了，没有OSW日志。

2.5 没有OSW日志，根因都分析不下去了，正打算放弃时，突然想到TFA中还有两个CHM日志压缩包。

2.6 分析解析后的CHM日志，如图所示：

 从这个解析后的CHM日志可以看很多信息：

1、这台主机的物理内存很大，有1TB的物理内存。

2、当前主机的空闲内存已经非常低，故障之前的这一个小时中，主机的空闲内存持续在7GB左右。

3、文件缓存吃了大概440GB左右的物理内存。当主机的剩余内存紧张时，会从文件缓存中释放内存。

4、没有出现我相像中的大量SWAPIN/SWAPOUT动作。这让我有点自我怀疑了，难道我的判断出现了错误？难道这个节点的内存使用不存在问题？集群的重启另有其他原因？

2.7 继续查看解析后的CHM日志，把时间线接近到故障前的几分钟。

 在这里，我发现了异常，CHM日志，采集的频率是5秒一次，23点58分05秒有一次日志采集动作，但下一次日志采集时间为23点58分33秒。之间的这二十多秒中，整个操作系统完全hang住，就连最简单的日志采集工作都无法完成。这也与前面出现的“网络无法通信”的时间正常吻合。正是由于操作系统无法响应，所以才出现了网络通信异常。

2.8 至此，可以非常肯定，就是因为主机的物理剩余内存不足，如果此时有大负载的业务出现，需要大量内存时，内核就只能从文件缓存中释放内存，最终造成整个系统出现短暂的hang死现象。

2.9 还有另外一个问题，既然内存使用这么紧张了，为什么没有出现相像中的SWAPIN/SWAPOUT动作？SWAP大小为32GB，内存使用如此紧张，但SWAP却一点也没有使用。 检查/etc/sysctl.conf文件，果然发现swappiness =0。

2.10 既然已经发现是内存使用过量，那么1TB的物理内存，是怎样被耗尽的？可能有很多方面的因素，但一个最明显的，并且是最浪费内存的地方，就是hugepage设置。

从前面的图片可以看出：hugepage设置了512GB，而实际上只使用了266GB。这就浪费了近250GB的内存。

3、案例建议

3.1 生产环境，建议都部署上OSW工具。

3.2 内存的分配和使用，一定需要关注，很多的案例，最终的源头都是内存问题。