AWR_RAC的一些指标解读

RAC一个实例慢会拖慢其他实例,RAC其实就是我为人人,人人为我

纵览RAC,先看report summary,再看top event的等待是否和RAC相关,如果等待事件和RAC相关则继续看RAC statisticMore RAC statistic

RAC对硬件的忍受能力比单节点差很多。所以差硬件搭出来的RAC性能还不如单节点

网络方面:如果Interconnect的网络延迟 > IO子系统的延迟,那么RAC本身就是性能瓶颈

存储方面:如果IO响应时间慢,那么log file sync慢,引起gc buffer busyRAC Redo flush慢造成gc buffer busy release/acquire等待)

反应Private Network性能的2个维度:

a)可用带宽: Estd Interconnect traffic (KB)

b)网络延迟: Avg message sent queue time on ksxp (ms)

 

 

 

RAC Cache Fusion(RAC缓冲融合 )

Cache Fusion就是通过互联网络在集群内各节点的SGA之间进行块传递,以避免首先将块推送到磁盘,然后再重新读入其他实例的缓存中这样一种低效的实现方式

RAC的cache等待事件主要是下图中的几个(gc就是global cache,11g的gc buffer busy在10g中就叫global cache buffer busy。产生的原因和单实例的 buffer busy waits 类似就是一个时间点节点a的实例向节点b请求block的等待。cr即consistent read

Cluster Wait事件并不孤立,会引发enq: TX - row lock contention等待事件出现更高的频率和更多单次等待耗时

 

 

Global Cache Load Profile

Global Cache blocks served就是send了

我们可以简略的看下实际传输的带宽=(received+send)*db_block_size=(Global Cache blocks received +Global Cache blocks served)*8K=901*8K=7.04MB/S=56.32Mb/S

实际传输的带宽=Estd Interconnect traffic (KB)=7744.30KB

所以我们只要心跳线带宽大于56.32Mb/S即可,目前一般都是千兆、万兆网卡,目前超五类线、超六类线都是千兆,超七类线是万兆

 

 

Global Cache Efficiency Percentages (Target local+remote 100%)

我们一般希望Buffer access - local cache %:占100%,其他两个越少越好,因为Global cache的传输我们希望一般只在本地,因为网络再快也不如访问本地内存快

 

 

Global Cache and Enqueue Services - Workload Characteristics

至关重要的2个指标Avg global cache cr block receive time (ms)、Avg global cache current block receive time (ms),结合其他节点的AWR报告一起分析这2个指标(一个节点receive time值小不代表其他节点也小,可能其他节点接收很慢receive time值很大), 一般要求小于2ms。若在RAC实例之间这2个指标差异很大,一般说明interconnect问题出现于OS buffer层或者网卡上

平均每个cr、current块从申请到收到的时间

比如都为10,则收到一个块就要10毫秒,那收100个块就是1秒,基本一个操作查询1M差不多100个块的大小的话就需要1秒。(一般磁盘物理读速率是100M/S,物理读一个块大概0.1毫秒

Avg global cache cr block receive time (ms)= 10 * gc cr block receive time / gc cr blocks received =10*458/4995=0.91

Avg global cache current block receive time (ms)= 10 * gc current block receive time / gc current blocks received=10*740/4005=1.84

上图数据来自Instance Activity Stats,458单位是百分之秒,而0.9单位是毫秒,所以需要*10

 

等待事件Gc cr[multiblock] request和本地Avg global cache cr block receive time (ms)是同步的,等待事件出现了那肯定receive time也大,和异地Avg global cache cr block flush time (ms)、Avg global cache cr block build time (ms)、 Avg global cache cr block send time (ms)三个指标相关,可以查看具体是哪个指标慢导致了receive time大或等待事件出现

等待事件Gc current[multiblock] request和本地Avg global cache current block receive time (ms)是同步,等待事件出现了那肯定receive time也大,和异地Avg global cache current block flush time (ms)、Avg global cache current block pin time (ms)、 Avg global cache current block send time (ms)三个指标相关,可以查看具体是哪个指标慢导致了receive time大或等待事件出现

本地Time to process CR block request in the cache=异地(build time + flush time + send time)

本地Time to process current block request in the cache=异地(pin time + flush time + send time)

但是receive time值并不是上面三者简单相加的值,我们姑且认为receive time是上面三者相加的一个结果。

pin time \build time \flush time \send time慢,那说明本地SGA和GRD慢,异地receive time慢

Flush time是在redo块上的操作。flush 是Oracle为了保证Instance Recovery实例恢复机制,而要求每一个current block在本地节点local instance被修改后(modify/update) 必须要将该current block相关的redo 写入到logfile 后(要求LGWR必须完成写入后才能返回),才能由LMS进程传输给其他节点使用。RAC Redo flush慢造成gc buffer busy release/acquire等待

上上图CR、Current两者的flush指标一般都要求<5ms,在Global CURRENT Served Stats中可以看到 current块的flush时间分布在哪些范围内

 

 

Global Cache and Enqueue Services - Messaging Statistics

Avg message sent queue time->一条信息进入队列到发送它的时间(在发送队列中的等待时间)

Avg message sent queue time on ksxp->对方一端收到该信息并返回ACK的时间,这个指标很重要,直接反应了网络延迟,一般要求小于1ms

Avg message received queue time ->一条信息进入队列到接收到它的时间(在接收队列中的等待时间)

% of direct sent messages->直接发送信息,在三者中占比越大越好

% of indirect sent messages->间接发送信息,一般是排序或大的信息

% of flow controlled messages->流控制最常见的原因是网络状况不佳, % of flow controlled messages应当小于1%

 

 

Global Cache Transfer Stats\Global Cache Transfer Times (ms)

图中busy对应的块就是gc buffer busy的块,可以看出gc buffer busy的块占总块数的百分比和gc buffer busy块的延迟时间

可以看出gc buffer busy的块占比分别cr为0.42%,current为3.39%

gc buffer busy的块延迟时间,cr块不大只有2ms,但是current就比较大了平均50ms,想象一下,gc buffer busy收到一个current块就要50ms,那收1万个块就要500秒,还好的是上图中gc buffer busy的占比不是特别高(也就是gc buffer busy块的总量不大)

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30126024/viewspace-2113551/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/30126024/viewspace-2113551/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值