问诊白求恩 - RAC 节点参数不一致引发的悲剧

编辑手记:在Oracle RAC中,有一些参数是数据库级别的,所有实例都使用同一个参数值,有些参数是实例级别的,实例间可以设置不一样的值。然而,对于部分实例级别的参数,节点间设置不同却可能引发故障。

在白求恩智能诊断平台上(https://bethune.enmotech.com),对于数据库参数的检测非常细致,根据参数对于数据库的影响大小,可以分为:性能类参数,稳定性类参数及规范操作类参数。

在我们诊断过程中,发现大部分人在参数的配置上比较随意。最常见的问题包括以下一些:

10g DRM参数配置

在Oracle 10g版本中,开始提出了DRM特性,默认情况下,当某个对象的被访问频率超过50时,而同时该对象的master又是其他节点时,那么Oracle则会触发DRM操作来修改master节点,这样的好处是可以大幅降低gc grant之类的等待事件。 在进程DRM操作的过程中,Oracle会将该资源的相关信息进行临时frozen,然后将该资源在其他节点进行unfrozen,然后更改资源的master节点。由于frozen的资源是GRD(Global Resource Directory)中的资源。在整个DRM的过程之中,访问该资源的进程都将被临时挂起。正因为如此,当系统出现DRM操作时,很可能导致系统或进程出现异常的。

Oracle DRM的Bug也非常多,尤其是Oracle 10gR2版本中,因此在10g的生产环境中,我们一般是建议关闭DRM特性的。

关闭DRM,常规的操作是:

_gc_affinity_time=0 _gc_undo_affinity=FALSE

但这2个参数是静态参数,也就是说必须要重启实例才能生效。实际上可以设置另外2个动态的隐含参数,来达到这个目的。

_gc_affinity_limit=250 _gc_affinity_minimum=10485760

甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的,在所有的节点上设置这2个参数之后,系统不再进行DRM。

RAC 全局事务处理

集群范围全局性事务(Clusterwide global transactions)是11g的新特性。集群范围全局性事务指的是在RAC中的每个节点均有一个本地事务,它属于一种分布式事务,当_clusterwide_global_transactions=true(default)时,Oracle会把这些本地事务当做一个事务对待,当_clusterwide_global_transactions=false时,Oracle会将这些本地事务当做单独的事务通过多阶段提交协调处理。

在默认设置为TRUE的情况下,可能会遭遇以下bug. Bug 13605839 ORA-600 [ktbsdp1] ORA-600 [kghfrempty:ds] ORA-600 [kdBlkCheckError]. Corruption in Rollback with Clusterwide Global Transactions in RAC ORA-00600: [kjuscl:!free]

因此,建议将该参数修改为FALSE,修改后不会对性能产生任何影响。

节点间LMS不一致引发的故障

LMS进程主要负责节点之间的数据交互,是RAC中最忙碌是一个进程。其默认值由系统的CPU数量计算得出,不同版本中的计算方法有差异。也可以通过gcs_server_process参数进行配置。一般情况下,要求节点之间的LMS进程数量一致。

接下来分享一个跟LMS相关的故障。

情景描述:一个批量执行的业务,时快时慢,经检查在执行计划完全一致的情况下,执行时间在2hour ~10hour 不等。

采样AWR报告,整体DBtime如下:

而这些DBtime主要消耗在RAC Global Cache环节。

这里对gc current grant 2-way等待事件简单说明:

gc cr&current grant 2-way 是一种 grant message package 的传递,当取cr 或current block 时向block master instance 请求x或s的权限 ,当请求的block在从任何实例上的buffer cache中都没有发现, lms进程会通知FG进程从disk 读取block到local buffer cache中

节点之间的等待如此长,是不是节点流量过大所以产生等待呢?

然而事实并不是这样,节点间流量很小。那么为什么会产生如此多的等待。

我们来分析RAC的Global Cache环节到底在做什么?

以cr块的访问为例,

Avg global cache cr block receive time= Avg global cache cr block build time+ Avg global cache cr block send time+ Avg global cache cr block flush time+ Avg message sent queue time on ksxp+ 其他

在上图中,我们发现以下四项相加的时间仅为0+0+3.1+0.2=3.3,与消耗的总时间87相差甚远。那么时间都到哪里去了?

我们通过AWR报告继续分析RAC的全局统计信息

我们发现,在最后一行,出现了流量控制,高达16.28。此处的数据为系统运行最慢的时候的,那么对比运行正常的时候发现,正常情况下,流量控制的值为0.8.

所以,16.28 vs 0.8.这是问题的关键!

但是,根据前面的分析,节点之间的流量并不大,为什么会做流量控制?

一把情况下,节点间做流量控制的原因有以下几条:

1、私网网络链路不通畅 2、RAC对端节点负载较高 3、两个节点的传输配置有差异

在这个案例中,前两者都不存在问题。那么就是两个节点的传输配置有差异。我们知道,节点之间数据传输是LMS进程执行的,因此,说明了LMS的配置有差异。

我们查询gcs_server_process 参数,发现没有配置。然后查看CPU数量,结果如下

果然是CPU不对等,因此,在lms 多的节点上(本案例的节点1 ) 有更强的cache fusion 请求的能力疯狂的抛向LMS进程小的节点(节点2)时, 节点2 的负载过重无法对称的处理, 就会出现这个性能问题。

Oracle为了避免这种攻击的产生,于是做了流量控制,导致系统中大量等待。

最后,我们手动修改了gcs_server_process 参数,使得LMS进程数量一致。问题得到解决。

白求恩,从架构到细节,全方位诊断系统安全与健康,比你更了解你的数据库。现在登录立即体验:https://bethune.enmotech.com

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-06-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏林欣哲

SpringBoot的微信点餐系统后台开发要点

项目设计 角色划分 买家(微信端) 卖家(PC端) 功能分析 ? 关系 ? 部署架构 ? 架构和基础框架 演进:单一应用架构->垂直应用架构->分布式服务架构-...

1.5K39
来自专栏京东技术

解决Hadoop的短板,实时大数据分析引擎ClickHouse解析

安海雄,京东系统架构师,从事架构设计与开发工作,熟悉各种开源软件架构。在Web开发、架构优化上有较丰富实战经历。

1193
来自专栏极客编程

PHP如何通过编程在服务端验证以太坊签名

以太坊有一个非常强大的JavaScript生态系统。有一些很棒的开源项目,比如ethereumjs-util,它提供了一个用以太坊帐户签名的即插即用功能。

562
来自专栏Kevin-ZhangCG

J2EE规范总结

1385
来自专栏北京马哥教育

性能调优攻略

关于性能优化这是一个比较大的话题,在《由12306.cn谈谈网站性能技术》中我从业务和设计上说过一些可用的技术以及那些技术的优缺点,今天,想从一些技术细节上谈...

2554
来自专栏牛客网

c++后台开发实习面经 - 今日头条

4.tcp的三次握手四次挥手的全过程和状态,为什么要四次挥手,为什么要经过TIME WAIT状态

753
来自专栏程序猿DD

Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)【Dalston版】

前言 在微服务架构中,我们将系统拆分成了一个个的服务单元,各单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行,依赖通过远程调用的方式...

1737
来自专栏张善友的专栏

在MongoDB中实现聚合函数

随着组织产生的数据爆炸性增长,从GB到TB,从TB到PB,传统的数据库已经无法通过垂直扩展来管理如此之大数据。传统方法存储和处理数据的成本将会随着数据量增长而显...

2007
来自专栏原创

五个最佳案例带你解读Node.js的前后之道

Node.js 是什么? Node.js采用C++语言编写而成,浏览器内核V8做为执行引擎;Node不是JS应用、而是一个Javascript的运行环境。Nod...

35210
来自专栏皮振伟的专栏

[linux][network]ICMP协议分析

前言: ICMP比较基础,说简单不简单,说难不难。 简单在于字段少,不能携带用户数据,没什么地方可以玩出太多花样;一般和它相关的就是ping和tracerout...

3186

扫描关注云+社区