墨菲定律:一个参数Drop_caches导致集群数据库实例崩溃

李真旭@killdb

Oracle ACE,云和恩墨技术专家

个人博客:www.killdb.com

在墨菲定律里,我们知道,有可能发生的故障就一定会发生,哪怕需要诸多因素的叠加才可能满足那复杂的先决条件。在以下案例中,我们抽丝剥茧,细致入微的追溯最终确定了导致数据库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 参数)

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

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

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

本文分享自微信公众号 - 数据和云(OraNews)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-04-06

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

微服务的鉴定与思考

微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能。举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: 接收库存 计算新...

24360
来自专栏CSDN技术头条

Apache Ignite——新一代数据库缓存系统

【编者按】飞速增长的数据需要大量存储,对这些数据的管理也不是一件容易的事。但相比于存储和管理,如何处理数据才是开发人员真正的挑战。对于TB级别数据的存储和处理通...

38290
来自专栏CSDN技术头条

CloudFlare:为什么能从富达、谷歌、微软、百度和高通筹到1.1亿美元?

CloudFlare是一家从事网络性能和安全领域的初创公司。创始人兼首席执行官Matthew Prince在7岁的时候就能编写了第一个没有Bug的计算机程序,还...

27870
来自专栏CSDN技术头条

详解 NoSQL 数据库的分布式算法

系统的可扩展性是推动NoSQL运动发展的的主要理由,包含了分布式系统协调,故障转移,资源管理和许多其他特性。这么讲使得NoSQL听起来像是一个大筐,什么都能塞进...

25790
来自专栏CSDN技术头条

用R & Python在云端运行可扩展数据科学

前言 如今,数据科学变得越来越复杂。这种复杂性由下面三个因素导致: 增长的数据生产能力 —— 环视四周,数的出多少个能产生数据的设备呢?如果你用笔记本电脑来浏览...

36770
来自专栏CSDN技术头条

N1QL为NoSQL数据库带来SQL般的查询体验

关系型数据库已经流行了超过40年,在这个过程中SQL也成为了操作关系型数据库的标准。SQL将数据的存储方式进行了包装和抽象,使开发人员可以专注于程序逻辑。对开发...

23890
来自专栏腾讯大讲堂的专栏

InnoDB 列压缩,提升 DB 性能

十年来腾讯游戏致力于带给玩家最好的快乐体验,腾讯游戏的后台数据库一直守护着亿万玩家的数据,提供稳定透明的服务。 腾讯后台数据库大部分使用的是MySQL数据库,现...

22390
来自专栏CSDN技术头条

MongoDB开发版本3.1.8发布

MongoDB 3.1.8版本已发布。值得注意的是此次3.1.8作为开发版本,并不适用于生产环境中使用。接来下的3.2系列版本将供广大用户作为生产环境中使用,敬...

23960
来自专栏CSDN技术头条

如果使用得当,MySQL也可以化身NoSQL

随着互联网和移动互联网的发展,各个机构都需要支撑远超过以往的数据。而在这个需求的刺激下,IT领域出现了大量数据处理技术,其中之一就是NoSQL。灵活的数据类型,...

21150
来自专栏企鹅号快讯

SQL笔记

表达式:表达式的定义非常简单 表达式可以返回一个值 表达式的类型非常广泛 它以包括各种 类型的数据如数字字符以逻辑型等其实在下列子句 如 SELECT 和 FR...

21760

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励