Exadata节点重启问题分析

问题概要:

2017年6月13号凌晨3点8分,Exadata上的CRM数据库的实例4 crash掉。

可以看到,在实例重启之前,没有例如:ora-600或ora-7445等错误,但有大量的TNS连接被中断,且操作系统进程被中止了。

问题分析:

(1)、查看数据库的alert日志:

在实例重启之前,数据库无非常明显的错误,但有大量的TNS连接被中断,且操作系统进程被中止了,在3点8分37秒,数据库实例重启。

(2)、查看ASM alert日志:

在3点8分5秒,ASM实例重启,但ASM实例重启之前,无明显错误信息。

(3)、查看集群日志:

从集群的日志可以看出,在13号的2点56分开始,该节点的集群资源大量处于超时状态。在3点整,CSS daemon中止运行。

(4)、查看集群OCSSD日志:

从集群的ocssd日志也只能看出,在3点整,CSS daemon中止运行,但并看不出是什么原因导致。

(5)、查看diskmon日志:

从diskmon的日志可以看出,OCSSD进程的中止是由diskmon进程发起的。原因是在3点整,crmdb4节点无法与xxx.xxx.xxx.13;xxx.xxx.xxx.14这个存储节点通信。为了避免脑裂的情景出现,所以diskmon强制中止ocssd进程。

(6)、原因分析:

目前的原因很清楚,是在3点整,crmdb4节点无法与xxx.xxx.xxx.13;xxx.xxx.xxx.14这个存储节点通信,而其它的计算节点可以与这个存储节点正常通信。那么存在以下几种可能性:

a. ib交换机有问题。

b. crmdb4节点的IB卡有问题.

c. crmdb4节点出现的某个资源瓶颈,导致操作系统hang死无响应,让整个集群误认为主机无法通信。

(7).查看IB交换机日志:

收集了两台IB交换机的Ilom snapshot:

从两台IB交换机的opensm.log日志可以看到大量以上的错误日志,但这些日志一直存在,且在13号凌晨3点左右,并未出现这些错误日志。

后来查询MOS,有信息表明这些IB交换机的错误日志可以忽略。所以并不是IB交换机导致了这次重启。其实这很好理解,如果真的是IB交换机出现故障,不可能只有一个计算节点无法与存储节点通信,还有就是这个计算节点重启后,问题就解决了。

(8).查看crmdb4计算节点的ilom snapshot日志:

说明该计算节点不存在IB卡的硬件故障。

(9).查看crmdb4计算节点的系统资源使用情况:

前面设想的三种情况,已经排除了两种,下面,我们来查看在3点前后,操作系统的资源使用情况。收集了2点至4点的exawatcher日志,但比较奇怪的是,这个时间段内,很多的信息竟然没有日志生成。最关注的vmstat,没有日志。

还好meminfo命令的输出日志保存完好:

可以看出,在13号的2点53分,swap free在变小。

如下图表1.15所示,是crmdb4计算节点的swapfree变化过程:


图1.15 crmdb4计算节点swapfree变化过程

可以看到,在某个时刻,swapfree竟然为0,继续搜索meminfo命令的输出日志文件:

搜索swapfree为0的数据,发现这时刻正好是13号的2点58分。

查看出现故障时计算节点IO的情况:

在13号的2点54分,crmdb4计算节点的本地磁盘IO为100%,而此时CPU的使用情况是system使用了12.41%,iowait使用了13.33%, user才使用10.91%,间接地说明了系统正在做大量的页交换工作,如果存在此时刻的vmstat日志,也可以印证这一点。

(10).找出真凶:

既然是因为swap空间被耗尽导致的故障,那我们就需要知道,是什么占用了大量的swap空间?我们需要查看ps命令的输出,如下图1.16所示:

图1.16 ps输出中查看占用虚拟内存较多的进程

SZ列表示,假如进程被换出,所需交换空间的大致大小。分析ps命令的输出,发现,都是goldengate相关的进程对应的SZ值最大。

下面,我们继续查看goldengate相关进程的交换空间变化趋势,以goldengate抽取进程extsbl在2点至3点之间的数据为例,如下图1.17所示:

图1.17 goldengate进程虚拟内存的变化趋势

可以看到,在2点至3点之间,goldengate抽取进程extsbl的交换空间使用从最开始的5GB多直接增长到出故障之前的12GB左右,除该抽取进程之外,其它的抽取进程,例如:EXT03、EXT04等等,也是类似的变化趋势。

询问得知,在13号晚上,数据有大量的更新操作,goldengate非常繁忙。如果有大事务,或长事务的存在,会导致swap空间被快速吃光,已经在大量的故障案例证实过这一点。

现在需要做的是,如何控制goldengate消耗大量的swap空间,其实goldengate提供了一个名为CACHEMGR CACHESIZE的参数,就是来解决这个问题。

跟现场运维的同事了解到,其实该客户的swap使用过量的问题一直都是存在的,在每个月的月结期间,都会收到swap相关的告警短信,但以前最多只使用到40%左右,所以未导致操作系统重启的故障发生,也就未太过关注,只是这次goldengate操作的数据量比以往更多,所以出现了问题。

建议:

既然知道了整个故障的来龙去脉,那我们要做的就是控制godlengate进程占用虚拟内存的使用率。在goldengate的配置参数中,有一个名为CACHEMGR CACHESIZE的参数,它就是防止在业务压力较大的情况下,goldengate进程耗光操作系统的SWAP空间。所以,我们只需要在goldengate的抽取进程中添加该参数即可解决问题。

未经允许不得转载:Oracle一体机用户组 » Exadata节点重启问题分析

相关推荐