Linux Bug: free cache 导致数据库实例crash

李真旭(Roger)

ACOUG 核心专家,Oracle ACE,云和恩墨技术专家

编辑手记:linux 文件系统的cache分为2种:page cache和 buffer cache.在RAC环境中,不同节点间的设置不合理很可能会触发操作系统bug,而引起数据库宕机。

这是1个月之前处理的某个客户的案例,现象大致是某天凌晨某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 操作来强制释放内存导致。 通过分析发现只能查看到最近几分钟的操作记录,如下

? 1 2 3 4 5 6 7 8 9

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

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

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

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

检查free memory

我们可以看到128G的物理内存,cache 就占据了88G的样子目前。

linux 文件系统的cache分为2种:page cachebuffer 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参数)

关于linux cache的一些知识请参考:

http://www.ibm.com/developerworks/cn/linux/l-cache/

File System’s Buffer Cache versus Direct I/O (文档 ID 462072.1)

----the end

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-09-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Netkiller

数据库进程间通信解决方案之MQ

数据库进程间通信解决方案之MQ 摘要 你是否想过当数据库中的数据发生变化的时候出发某种操作?但因数据无法与其他进程通信(传递信号)让你放弃,而改用每隔一段时间查...

3684
来自专栏PHP技术大全

Web安全开发规范手册V1.0

团队最近频繁遭受网络攻击,引起了部门技术负责人的重视,笔者在团队中相对来说更懂安全,因此花了点时间编辑了一份安全开发自检清单,觉得应该也有不少读者有需要,所以将...

670
来自专栏超然的博客

web攻击

  最常见和基本的攻击WEB网站的方法。攻击者在网页上发布包含攻击性代码的数据。当浏览者看到此网页时,特定的脚本就会以浏览者用户的身份和权限来执行。通过XSS可...

711
来自专栏北京马哥教育

利用tcpcopy引流做模拟在线测试

一、工具介绍 Tcpcopy是一个分布式在线压力测试工具,可以将线上流量拷贝到测试机器,实时的模拟线上环境,达到在程序不上线的情况下实时承担线上流量的效果,尽早...

2794
来自专栏邹成卓的专栏

简单的 web 安全 checklist

本文根据以往nodejs web服务开发过程中踩过的坑,以及腾讯安全平台部的漏洞修复指引总结而来,列出了nodejs web服务开发过程中比较常见的一些安全问题...

6130
来自专栏杨建荣的学习笔记

数据整合式迁移的一些总结(r8笔记第38天)

说起数据迁移,感觉也算是有些感受了,但是最近参与的几个迁移案例还是和以前大大不同,以前的迁移项目是比拼停机维护时间,尽可能在短时间诶导入大批量的 数据,有参与表...

3065
来自专栏日常学python

搭建属于自己的代理ip池

这是我的第六篇原创文章 继上一篇说了反爬虫之后,我说今天这篇文章会搭建一个属于自己的代理ip池,所以,为了不食言,就写了这篇文章,那好废话不多说,进入正题 1 ...

4179
来自专栏北京马哥教育

Zmap详细用户手册和DDOS的可行性

0x00 背景 Zmap是美国密歇根大学研究者开发出一款工具。在第22届USENIX安全研讨会,以超过nmap 1300倍的扫描速度声名鹊起。相比大名鼎鼎的nm...

33410
来自专栏编程坑太多

Python构建私有代理IP库

1718
来自专栏一名叫大蕉的程序员

合格的配置中心应有的素养No.76

最近在看配置中心的一些设计,好像基本都是五花八门,主要看的是还是携程的 Apollo 这个开源的配置中心项目。一直以来都觉得配置中心很重要,因为这对于灰度发布,...

1718

扫码关注云+社区