原文地址：https://i-blog.csdnimg.cn/blog_migrate/31f2cbc738639a4aaad7d37e758e1f51.png

 

在墨菲定律里，我们知道，有可能发生的故障就一定会发生，哪怕需要诸多因素的叠加才可能满足那复杂的先决条件。在以下案例中，我们抽丝剥茧，细致入微的追溯最终确定了导致数据库RAC实例崩溃的微小原因。

 

这是一个真实的客户案例，可以概括为一条参数引发的血案。现象大致是某天凌晨某 RAC 节点实例被重启了，通过如下是 alert log 我们可以发现 RAC 集群的节点2实例被强行终止掉了，如下是详细的告警日志信息：

 

 

从上面的日志来看，在2：03分就开始报错 ORA-00600，一直持续到2:39分，lmd0 进程开始报同样的错误；然后接着 LMD0 进程强行把数据库实例终止掉了。。直接搜索 Oracle MOS，看上去有点类似这个 bug，不过很容易就可以排除。

Bug 14193240 : LMS SIGNALED ORA-600[KGHLKREM1] DURING BEEHIVE LOAD

 

从日志看，2:03分就开始报错，然而直到 lmd0 报错时，实例才被终止掉，也就是说 lmd0 报错才是问题的关键。那么我们首先来分析下 lmd0 进程的 trace 文件内容，如下所示：

 

 

从上面的信息来看，确实是内存 heap 存在错误的情况。根据 Oracle MOS 文档：

 ORA-600 [KGHLKREM1] On Linux Using Parameter drop_cache On hugepages Configuration (1070812.1) 的描述来看，此次故障跟文档描述基本上一致，如下：

 

 

 

其中地址 [0x679000020] 后面的内容也均为0，跟文档描述一样，其次，文章中提到使用了linux 内存释放机制以及同时启用了hugepage配置。

 

根据文档描述，这应该是 Linux bug。通过检查对比2个节点配置，发现节点2的配置确实不同：

当 drop_caches 设置为3，会触发 linux 的内存清理回收机制，可能出现内存错误的情况；然而我们检查配置发现并没有修改：

 

 

因此，我认为是之前人为进行了 echo 3 > /proc/sys/vm/drop_caches  操作来强制释放内存导致。    通过分析发现只能查看到最近几分钟的操作记录，如下：

 

 

看操作记录确实发现了操作，那么同时检查操作系统日志也发现了一些蛛丝马迹，如下：

BUG: soft lockup - CPU#1 stuck for 10s! [rel_mem.sh:13887

 

可以看到也确实出现了 drop_cache 的相关操作。大家注意看上面红色的地方，提到了是执行了一个 shell 脚本，然后还导致一共 cpu stuck 了，而且也能看出该脚本是在执行回收 cache 的动作。

 

我坚持认为客户环境上肯定进行了强制的内存回收，但是客户说他们没有进行任何人为操作，不过经过我检查发现确实有一个 crontab 脚本。

 

 

那么为什么主机上会部署这样的脚本呢？ 我猜想肯定是操作系统的内存使用率看起来很高，通过检查发现确实如此：

 

我们可以看到128G的物理内存，cache 就占据了 88G 的样子目前。linux 文件系统的 cache 分为2种：page cache 和 buffer cache, page cache 是用于文件，inode 等操作的 cache，而 buffer cache 是用于块设备的操作。从上面的数据来看，我们所看到的 free -m 命令中的 cached 88552 全是 page cache。而实际上该数据库实例的内存分配一共也就40G，且使用的是 linux raw。

 

 

我们可以看到，整个主机物理内存为128G，而 Oracle SGA+pga 才40g，另外将近 90G 的内存都是 fs cache 所消耗。完全可以调整 linux 的参数去释放 cache，而不需要使用 echo 这种比较暴力的方式；根据 Oracle mos 的几个文档的描述，推荐设置如下几个参数：

sysctl -w vm.min_free_kbytes=4096000

sysctl -w vm.vfs_cache_pressure=200

sysctl -w vm.swappiness=40   （老版本的 linux 是设置 vm.pagecache 参数)