细致入微:Oracle RAC DRM引起性能问题案例一则

  1. 云栖社区>
  2. 数据和云>
  3. 博客>
  4. 正文

细致入微:Oracle RAC DRM引起性能问题案例一则

行者武松 2017-07-17 17:55:44 浏览1491
展开阅读全文

640?wxfmt=jpeg&wxfrom=5&wx_lazy=1

熊军(老熊)

云和恩墨西区总经理

Oracle ACED,ACOUG核心会员


编辑手记今天在『云和恩墨大讲堂』微信群,有朋友问到DRM问题,这让我想起老熊之前的一篇文章案例,虽然是关于Oracle 10g的,但是其思路和分析过程值得学习借鉴,收录在这里,供大家学习参考。


客户一套运行在Oracle 10.2.0.5 RAC上的系统,间歇性地出现性能问题。其性能现象为前台反映性能缓慢,从系统上看CPU利用率大幅增加,load增加。这种性能问题通常在出现几分钟后自动恢复正常。

从AWR中的TOP 5等待来看:

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

可以看到,TOP 5中,有3个是latch相关的等待,而另外2个则是跟RAC相关的等待。
如果再查看更细的等待数据,可以发现其他问题:

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

从上面的数据还可以看到,除了TOP 5等待,还有:

"gcs drm freeze in enter server mode“以及"gc remaster"

这2种比较少见的等待事件,从其名称来看,明显与DRM有关。那么这2种等待事件与TOP 5的事件有没有什么关联?。

MOS文档:

"Bug 6960699 - "latch: cache buffers chains" contention/ORA-481/kjfcdrmrfg: SYNC TIMEOUT/ OERI[kjbldrmrpst:!master] [ID 6960699.8]”

提及,DRM的确可能会引起大量的"latch: cache buffers chains"、"latch: object queue header operation"等待,虽然文档没有提及,但不排除会引起”latch: cache buffers lru chain“这样的等待。

为了进一步证实性能问题与DRM相关,使用tail -f命令监控LMD后台进程的trace文件。

在trace文件中显示开始进行DRM时,查询v$session视图,发现大量的 "latch: cache buffers chains" 、"latch: object queue header operation"等待事件,同时有"gcs drm freeze in enter server mode“和"gc remaster"等待事件,同时系统负载升高,前台反映性能下降。

而在DRM完成之后,这些等待消失,系统性能恢复到正常。

看起来,只需要关闭DRM就能避免这个问题。怎么样来关闭/禁止DRM呢?很多MOS文档提到的方法是设置2个隐含参数:

_gc_affinity_time=0  

_gc_undo_affinity=FALSE  

不幸的是,这2个参数是静态参数,也就是说必须要重启实例才能生效。
实际上可以设置另外2个动态的隐含参数,来达到这个目的。按下面的值设置这2个参数之后,不能完全算是禁止/关闭了DRM,而是从”事实上“关闭了DRM。

_gc_affinity_limit=250  

_gc_affinity_minimum=10485760  

甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的,在所有的节点上设置这2个参数之后,系统不再进行DRM,经常一段时间的观察,本文描述的性能问题也不再出现。

下面是关闭DRM之后的等待事件数据:

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

那么什么是DRM?DRM对系统来说有什么好处?下面的文档已经描述得比较清楚,有兴趣的朋友可以参考:

  • MOS文档:DRM - Dynamic Resource management [ID 390483.1]

DRM简单来说就是Oracle根据数据块的访问来动态调整管理数据块的主节点,这项技术在引入之初引发了一系列的性能问题。


本文出自数据和云公众号,原文链接


网友评论

登录后评论
0/500
评论
行者武松
+ 关注
所属云栖号: 数据和云