listener异常掉线原因分析

客户反映10点半,ebank数据库节点1 (AIX平台)应用报连接缓慢,登录进去后命令运行很慢,监听掉了,没在线,手工启动后,恢复了,抓取了日志和性能报告,要求进行分析。

查看数据库实例的告警日志

监听的问题本来应该看监听和群集(注:这套库运行在11.2.0.3 GI环境下)的日志,不过客户发来的东西先看看。

listener异常掉线原因分析

可以看到问题始于10:22:56,当时已经出现性能过载,导致VKTM发生超时(如果没有进行时间同步的话),后续LMHB的slave启动失败,然后大量的dedicated server无法及时启动,client超时中断,导致TNS-12560和ORA-609报错,均与性能过载有关。

awk报告

首先%iowait达到15%,这还是10:00~10:41的平均值,10:22开始应该更高。TOP 5等待首先是log file sync,平均等待96ms,其次是enq: SQ – contention,平均等待6.1秒,其他等待占比在5%以内。

对于log file sync而言,log file parallel write很低,平均不大1ms,tablespace IO显示前三位表空间的平均读时间在5ms以内,但平均写时间都在0.1秒以上;

enq: SQ – contention,与sequence的使用竞争有关,一般是建议缓存;

后台等待事件的前三分别是enq: PR – contention、enq: PV – syncstart和os thread startup,平均等待时间分别是83秒、131秒、7.8秒。enq: PR – contention与mmon启动slave有关,enq: PV – syncstart则是启动同步相关的slave。

性能报告说明了什么?可以断定性能过载来自内存。当系统内存进入颠簸状态,高频的pi/po本身具有较高的优先级,阻止别的进程取得CPU时间片运行,更重要的是AIX会挂起新的进程,直到内存颠簸降到阈值以下。这很好地解释了后台的前三等待,那么top 2等待呢?由于系统内存紧张,数据库buffer(或共享池)的一部分已经换出到换页空间,这样数据库访问Log buffer或者sequence cache时,所访问对象实际上并不在物理内存中,从磁盘page in之后,必然带来较大的延迟,从而产生相应的等待。

让客户传来alog -t console -o和lsps的输出,换页空间在故障时间点高达65%,console日志没有特别的提示,但有非数据库进程启动障碍的告警,说明客户环境碰到的问题是全系统层面,并非仅是数据库自身的问题。

后续客户应该做好内存的配置,和paging的监控,对内存瓶颈最好提前应对。

版权声明

文章来源:银信长远 作者:慕容荃

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论