问题描述
某日,客户的系统突然出现故障,业务系统无法使用。DBA发现三节点的集群突然变慢,其中1号和2号节点的数据库均无法正常使用。
晚上19点左右接到报障后,老白立即远程登录进行处理,由于当时是客户的业务高峰期,因此首要是恢复系统运行,然后再开展问题调查,消除故障隐患。
通过HANGANALYZE分析发现1节点大量会话HANG住,并且存在大量GC BUFFER BUSY WAIT等待的会话,杀掉其中几个阻塞严重的会话后,ZZZOSS1恢复正常。
在处理ZZZOSS2的时候发现2号节点也存在大量HANG住情况,杀了数个阻塞会话后,仍无法恢复,只能采取重启的方式。重启2号节点后,系统恢复正常。
分析过程
通过ALERT LOG检查发现,18:53分ZZZOSS3出现了故障,并且进行了自动重启,自动重启后,就出现了集群3个节点全部HANG住的现象。HANG住的主要原因是ZZZOSS1,ZZZOSS2在帮助ZZZOSS3做实例恢复时出现了大量的全局热块冲突,从而导致RAC INTERCONNECT故障。ZZZOSS3被驱逐的主要原因是18:52分时ZZZOSS1,ZZZOSS2与ZZZOSS3的lms通讯突然发生异常。从而导致ZZZOSS1,ZZZOSS2认为ZZZOSS3出现了故障,从而驱逐ZZZOSS3。
通过对ZZZOSS3相关LMS进程日志的分析发现:
LMS进程在等待56/57号闩锁,通过V$LATCHNAME查一下相关闩锁的名称:
56号闩锁是OS PROCESS:request allocation,这和进程的内存分配有关,57号闩锁是kair sga latch,和SGA内存管理有关。出现这两个闩锁等待,首先怀疑是操作系统的内存出现了问题。
于是检查ZZZOSS3的nmon日志,发现从18:45分左右开始,物理内存空闲比例大幅度下降,并且在18:51分开始出现了大量的系统换页。从而可以初步断定操作系统换页是该问题的最主要原因。
故障原因
- 由于几天前客户做操作系统升级失败,操作系统升级回退后,以前调整过的参数maxperm%恢复为系统缺省的80%(为防止类似故障出现,之前3个节点的maxperm%都已经修改为15%),因此大量物理内存被文件缓冲占用,一旦系统有大内存需要,可能导致严重换页,从而导致LMS进程无法获得足够的操作系统资源和时间片,和其他节点通讯异常,从而导致节点分裂
- 节点分裂后,在做实例恢复的时候,出现了RAC GCS问题,而DRM没有关闭,从而导致数据库HANG住
处理方案
- 将maxperm%修改为15%
- 关闭DRM
作者:白鳝