RAC一个实例慢会拖慢其他实例,RAC其实就是我为人人,人人为我
纵览RAC,先看report summary,再看top event的等待是否和RAC相关,如果等待事件和RAC相关则继续看RAC statistic(More RAC statistic)
RAC对硬件的忍受能力比单节点差很多。所以差硬件搭出来的RAC性能还不如单节点
网络方面:如果Interconnect的网络延迟 > IO子系统的延迟,那么RAC本身就是性能瓶颈
存储方面:如果IO响应时间慢,那么log file sync慢,引起gc buffer busy(RAC 的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/