oracle vm.drop_caches,墨菲定律一个参数Drop_caches导致集群数据库实例崩溃
墨菲定律一个参数Drop_caches导致集群数据库实例崩溃
墨菲定律:一个参数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)
本文出自数据和云公众号,原文链接
墨菲定律一个参数Drop_caches导致集群数据库实例崩溃相关教程
oracle vm.drop_caches,墨菲定律一个参数Drop_caches导致集群数据库实例崩溃相关推荐
- 墨菲定律:一个参数Drop_caches导致集群数据库实例崩溃
李真旭@killdb Oracle ACE,云和恩墨技术专家 个人博客:www.killdb.com 在墨菲定律里,我们知道,有可能发生的故障就一定会发生,哪怕需要诸多因素的叠加才可能满足那复杂的先决 ...
- ORACLE RAC 11.2.0.4 ASM加盘导致集群重启之ASM sga设置过小
最近,一同事为一2节点的ORACLE RAC 11.2.0.4集群ASM加盘,没有注意到ASM的sga设置过小,加盘reblance时导致集群重启.详细描述如下: 1.问题描述 ORACLE RA ...
- 我的读书笔记 -《墨菲定律》
2019-2-15 其实我是不想写这本书的总结的,因为说实在话,就一个墨菲定律就能够概括整本书,他下面所有的小标题又能够概括每一小节,每一小节都是墨菲定律从某一方向的延伸或者实例. 墨菲定律:如果有两 ...
- 高级程序员必会的程序设计原则 —— 墨菲定律及防呆设计
前言 如果你或你带领的团队经常会写出一些BUG,日常不是在解决BUG就是在解决BUG的路上,那么你的项目一定是应验了墨菲定律,并且在开发时并没有足够考虑防呆设计.团队越是疲于奔命,错的越是多. 简记 ...
- 墨菲定律:都是温度惹的祸
作者:卓晴博士,清华大学自动化系 更新时间:2020-08-14 Friday 卓大,这是今天西部赛三个采用恩智浦的队伍发生了,相同的问题.真的不是场地原因吗?我们懂不能做温室的花朵,但是室外阳光斜射 ...
- 管理学定律--墨菲定律
如果有两种或两种以上的方式去做某件事情,而其中一种选择方式将导致灾难,则必定有人会做出这种选择.根本内容是:如果事情有变坏的可能,不管这种可能性有多小,它总会发生. 一.墨菲定律来源 1949年,一位 ...
- 墨菲定律 三种(is2120)
//z 2012-09-11 08:46:41 IS2120@CSDN.T2699303400[T29,L404,R7,V202] 根据"墨菲定律": 一.任何事都没有表面看起来那 ...
- 生活中的定律——墨菲定律
凡是可能出错的地方,就一定会出错. Anything that can go wrong will go wrong. --爱德华·墨菲,来自美国空军的一位工程师上尉. 墨菲定律 或许你之前从未耳闻墨 ...
- 墨菲定律 Murphy’s Law
墨菲定律(英语:Murphy's Law),又译为摩菲定律,具体内容是"凡是可能出错的事就一定会出错",指的是任何一个事件,只要具有大于零的机率,就可确定它可以发生. 主要内容: ...
- 【产品】建立墨菲定律思维模式
1949年,一位名叫墨菲的空军上尉工程师,认为他的某位同事是个倒霉蛋,不经意间开了句玩笑:"如果一件事情有可能被弄糟,让他去做就一定会弄糟." 这句话迅速流传,并扩散到世界各地. ...
最新文章
- 美团面试题:JVM 堆内存溢出后,其他线程是否可继续工作?
- Mac zsh切换bash bash切换zsh
- (转)python中的*args和**kw到底是个啥。看下面的例子就会懂了
- nginx中文件路径表示方法
- 10.30PMP试题每日一题
- 设计模式总结篇系列:工厂方法模式(Factory Method)
- 洛谷——P1067 多项式输出
- JMeter插件模拟发送UDP请求:UDP sampler
- 用pycharm写python老是提示错误_python pycharm错误集锦
- PA塑料EN45545-2:2020R22 HL3防火检测的难易程度
- libGDX游戏开发之NPC敌人事件(六)
- 手机如何把PDF文件压缩的小一点?教你手机压缩文件方法
- Java StackTraceElement源码总结 StackTraceElement源码注释翻译和解析中英文对照版
- python南京招聘现状_岗位招聘情况分析之---Python
- 软件测试自学还是培训?
- zencart模板修改的地方
- java ftp 假死_FTPClient下载文件程序假死问题
- 【复】从0到1的 selenium 爬虫经历
- Retrofit 大体框架
- yolov3与yolov4效果对比_知识精讲 | Yolov3和Yolov4核心内容、代码梳理_创事记(5)