love wife & love life —Roger的Oracle&MySQL技术博客

Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

The database instance Crash because the CPU High ?

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger的Oracle&MySQL技术博客

本文链接地址: The database instance Crash because the CPU High ?

某系统的其中一个RAC节点的db实例被干掉并自动重启了,如下是该实例的alert log信息:

我们可以看到,该实例在13:17:07 秒被LMS0进程强行终止掉了,接着该实例在13:17:17 被正常启动。
在该实例被强行终止之前,有一点关键信息是值得我们注意的,如下:

从这部分信息,我们可以大致判断,在13:16:56时,Oracle已经发现LMON进程长时间没有检测到心跳了,这个时间长达204秒。
如果根据时间向前推进,在13:13:32时间点,实际上Lmon进程就开始出现异常了。 我们也可以看到在13:13:45时间点,出现了
一个ora-3136错误。一般来讲,这个waring跟系统的负载可能有极大的关系,例如资源使用极高,可能出现超时的情况。

从alert log信息来看,Oracle 让我们去查看LMD0/LMS0 以及diag的信息来进行进一步的分析。那么我们首先就来看一下LMD0进程的信息:

从LMD0进程的信息来看,可以发现该进程(lmd0)已经等待了258秒,等待事件为ges remote message,除此之外,没有其他的信息了。

既然这样,那我们继续来看下LMS0进程的信息:

LMS0进程的信息似乎也没有太多的价值。最后我们只能看看diag的信息了,Oracle在将所有进程kill之前进行了一次dump。

从前面的load来看,load信息如下:
loadavg : 62.17 35.29 18.12

这里简单解释一下,这3个loadavg值表示该主机分别在1分钟,5分钟,15分钟内的平均load值。 显然,这里我们不看后面2个指标了。
根据时间点,我们这里看第一个loadavg值是62.17. 这个值已经超出CPU的数倍了,由此我们不难判断在13:16:56向前推进1分钟的时间内
系统的load是极高的。

对于LMON进程,主要是监控RAC的GES信息,当然其作用不仅仅局限于此,其还负责检查集群中每个节点的健康情况,当有节点出现故障是,
负责进行reconfig以及GRD(global resource Directory)的恢复等等。我们知道AC的脑裂机制,如果IO fencing是Oracle本身来完成,也
就是说由CLusterware来完成。那么Lmon进程检查到实例级别出现脑裂时,会通知clusterware来进行脑裂操作,然而其并不会等待clusterware
的处理结果。当等待超过一定时间,那么LMON进程会自动触发IMR(instance membership recovery),这实际上也就是我们所说的
Instance membership reconfig。

对于报错中提到的LMON进程无法获得心跳了,那么LMON进程的心跳是什么呢? lmon进程主要通过2种心跳机制来判断集群节点的状态:

1) 网络心跳 (主要是通过ping进行检测)
2) 控制文件磁盘心跳,类似ckpt进程每3s更新一次controlfile的机制。

那么什么情况下,会导致LMON无法获得心跳呢?

一般来讲有可能是该进程无法获得latch或者系统的资源不足,导致LMON进程无法正常工作。而这里我们也确实发现系统的load极高。
从上面的进程详细信息来看,我们也确实发现该进程一直在等待一个latch,同时有其他的10个进程正在等待LMON进程,这其中的等待
就包括LMON,ASMB,ckpt进程等等。从diag的dump来看,提示lmon进程已经等待了216秒。

从process dump我们还可以看到该进程一直无法获得的latch是可能是被如下进程所持有:

possible holder pid = 792 ospid=15095

不过可惜的是,我搜索diag日志,居然找不到pid 792这个会话。 我们知道diag的trace中的process state dump信息是根据PID排序的。
我发现dump内容到process 69就结束了。从PID来看,该实例在出问题的时候,起码都800个process以上,dump的内容不可能只有这么一点。

从2节点的核心进程的日志也看不到有价值的信息。后面监控了一段时间发现该节点cpu几乎都是90%以上,很多时候甚至100%。

检查发现是CBC latch,而且都是一些报表的SQL。

对于这个case,我仍然感觉可能是资源异常导致LMON进程异常,最后Oracle 检测到该进程长时间没有心跳,最终终止了该实例。

基于这个假设,我打算在自己的VM Rac环境(Linux +10.2.0.5)测试一下,如果某个节点CPU使用率极高的情况下,是否会导致LMON进程异常。

不过遗憾的是,我并没有模拟出这种情况,如下是我的模拟过程:

利用shell 来模拟cpu的消耗:

调用该脚本即可:
[root@rac1 ~]# ./kill_cpu.sh 1
kill  17449 ;

这样测试了10分钟,发现Rac毫无反应,于是我又模拟了latch: cache buffer chains. 以此来尽可能的将该节点的CPU消耗光。

如下是该节点的CPU使用情况:

我们可以看到在08:43:16 到 08:46:44 之间,rac 节点1其实hang了很长时间,可惜这个数据库节点都没有挂。

我只能说Oracle 太强悍了,我檫。

One Response to “The database instance Crash because the CPU High ?”

  1. Amn Says:

    根据时间点,我们这里看第一个loadavg值是62.17. 这个值已经超出CPU的数倍了,由此我们不难判断在13:16:56向前推进1分钟的时间内系统的load是极高的。

    Hi,Roger。怎么由loadavg值是62.17, 这个值已经超出CPU的数倍了得出系统的load是极高的这个结论?不明白,请指教。

Leave a Reply

You must be logged in to post a comment.