10gRAC培训 – 2 and last

on

为期4天的10g RAC培训结束了,必须承认这4天的收获非常大,解答了很多我以前一直迷惑的地方,并且获得了大量诊断和调优RAC系统的经验。Su和Roy的技术实在让人佩服。

对于AWR报告中RAC部分的表述,对于RAC每个重要等待事件的含义,对于Cache Fusion的每一步动作,对于CRS相关的log和trace,对于Load Balance的处理,对于Dynamic Resource Management的机制,这些都是我以前感到疑惑的地方,在这次培训中都得到了几乎完美的解答。

举一个简单的例子,如果有人问我,“RAC环境中如果一个实例在自己的Cache中找不到需求的block,那么它就会请求从另外一个实例中获得这个block,那么如果有更多的节点,这样的请求过程会很消耗资源吗?8个节点下的这种情况会比2个节点更消耗资源吗?”在这次培训之前,我无法回答,甚至我会说,恩,也许是的吧。但是,现在我可以很清楚地回答,NO!因为在一次gc block request中最多只会有3个block参与到其中,而不管环境中有多少个节点,这就是master block的作用,每次request的过程是requester -> master -> holder。

其实并不局限在RAC部分,纯RDBMS的知识也得到了完善,再举一个例子。对于性能报告中CPU Time这个等待事件我一直感到疑惑,这到底表示了什么?CPU Time位于Top 5 wait event中表示了什么?我还在网上跟Fenng聊过这个问题,也仍然抱有疑惑。然而,现在我知道,我们忽略Top 5中的CPU Time并不是因为它是Idle wait也不是因为我们要从其它的等待中判断CPU Time等待,我们忽略它是因为CPU Time就是说明系统在利用CPU干活,实际上这不是一个等待事件,CPU Time高表示系统在干活,而这是个好的现象,因为系统并没有把时间耗费在Wait上。Elapsed Time = CPU Time + Wait Time,所以甚至我们可以说CPU Time越高越好

有太多的资料和学习笔记需要整理,今后应该会陆续把Topic写成文章的,不过不会很快,因为之后几天我得休息一下,然后把报销搞定,还有琢磨一下新入手的Nokia N95。

BTW: RAC Pack的宗旨是高举Oracle的三个代表 - CRS, ASM, RAC。

Update@2011-1-9
今天再回顾3年前的这段话,发现当时自己对于CPU Time在数据库整体等待事件中的含义还是不太清晰的,应该说piner当时的话更符合我现在的理解。在一个正常的系统中,虽然仍然不需要特别去关注CPU Time,但是如果在AWR报告中看到CPU Time占据了80%甚至90%的DB Time,那么如果不是这个系统确实很闲那就是这个系统有某些问题。因为数据库在正常承载应用的时候,如果绝大多数时间都是CPU在运算,那么就意味着I/O时间很小,这在大多数环境中是不正常的。
一些概念在DB time VS. DB CPU中进一步清晰。

BTW:3年前还是Nokia鼎盛的时期,那时候正入手Nokia N95,然而到了2010年,Nokia在Apple iPhone和Google Android的强大攻势下,已经面临再不转身就会被抛下的局面,真是一朝天子一朝臣。

16 Comments Add yours

  1. 木匠 says:

    那么趁着你正热乎着, 帮忙给分析看看下面这个等待时间的起因和解决方法:

    Wait: gc current request, Class: Cluster

    Oracle 10.1.0.4 RAC on Linux

  2. kamus says:

    在数据库的I/O中有current read 和 consistent read,在RAC中也是一样,请求从Global Cache中获取current block到最后获取到这个block之间的等待就是gc current request,如果是尝试获取consistent block,那么就是gc cr request等待。这是概念。
    那么如果gc current request位于Top 5中,首先要看ave wait time是多少,通常这个值应该在5-8个msec,如果是2位数的话,那么表示gc block的获取速度是比较慢的。
    至于为什么比较慢,就需要详细判断原因了。
    可以查一下AWR Report中是不是还有其它的gc等待,比如gc current block busy或者gc current buffer busy,这可能是热点块的问题。
    还可以查一下有没有gc block lost,这个lost应该趋近为0,因为每次lost都是在6个timeout之后才会发生,而每个timeout需要1s,这样如果有一次block lost就会消耗6s的时间,这会严重降低gc current request的平均等待时间。
    另外因为gc通讯都是通过lms进程完成的,那么可以通过10046 trace本地客户端进程,再同时通过10708 trace另外节点的lms进程,互相比较,就可以明确的知道到底gc block request是慢在哪里了。

  3. victor666666 says:

    RAC我见过的一般都是2、3个节点,遇到的工程师都胜传4~6个节点时db慢的不行,想了一下,如果对于一个点如A节点(相对于剩下的节点既是master也是requester),是不是RAC中的点越多,对A点的请求或A对其它点的请求会越多,导致了资源紧张,尤其是在load balance做了session分摊的情况下

  4. big_bear says:

    真羡慕楼主有这样的机会啊,期待楼主能够把培训资料整理发表出来。

  5. 马艺桐mayitong@hotmail.com says:

    10708 trace另外节点的lms进程,楼主能否贴出一个TRACE 分析一下

  6. 木匠 says:

    Thanks 10k. 你的提示非常具有技术的先进性! 哈哈.
    看来我03/04年在Oracle R&D积累的RAC知识已经过时了.

    “gc current request”主要出现在 长事务 实时监控报告里面,
    总体到数据库级别, 倒不明显.
    反而gc cr grant 3-way出现在了top 5 wait events (Top 5 Timed Events) 中.

    4 个节点的AWR都给你email过去了.

  7. kamus says:

    @木匠
    暂时还没有时间看你的awr,不过我会看的。gc cr grant 3-way是这样产生的,一个节点需求一个cr block,此时需要询问master,但是此block的master不在自己实例上,这样是一次网络hop,master发现这个block在另外的实例上,于是告诉另外那个实例把block传给这个请求的实例,这又是一次网络hop,另外的实例给这个实例一个lock(这是grant)让这个实例自己去从disk上读取block,这是第三次网络hop,整个这个过程就是3-way的gc cr grant,通常这个等待下面会跟随着一次磁盘I/O。

  8. kamus says:

    @victor666666
    这种情况理应不会出现,因为oracle会按照很简单的平分规律在所有节点中平均放置block的master,因此几乎不可能所有block的master都在A节点上,除非因为所有的检索更新操作都在A节点上完成,由于DRM所以master block被全部动态转移到A节点上了,这个跟是10gR1还是10gR2也有关系,这两个版本处理的机制是不一样的,10gR1是DYNAMIC FILE AFFINITY,10gR2是DYNAMIC OBJECT AFFINITY,这个要讲就讲多了,希望尽快有时间写出文章来吧。
    你可以尝试使用_gc_undo_affinity=false和_gc_affinity_time=0 来禁用DRM,这样对于多节点的RAC环境应该会有性能的改善。

  9. piner says:

    cpu time多也不一定是好事,只有相对,没有绝对.

  10. piner says:

    一般的OS中,wait 是可以被利用的,cpu利用高,很大程度表示逻辑读高,而你的系统是否应当有这么高的逻辑读?

  11. kamus says:

    @piner
    自然不是绝对的,但是通常来说是没有问题的。
    因为如果是逻辑读高,那么应该会有其它的相关等待事件浮出水面,比如buffer busy等,所以不论何种情况CPU Time应该都不用作为关心的对象

  12. piner says:

    buffer busy不一定的,我们的系统,这个cpu time高一般都是逻辑读高,或者是大规模计算型函数。
    带来的就是负载的升高,调整掉这些就好了,其实要明白一点,逻辑读与一些计算型函数,耗费的就是cpu,如果能减少他们,当然是好事情。

  13. kamus says:

    你这样的说法当然也没有问题。
    本来需要耗费30%的CPU Time在不降低负载的情况经过调优(比如优化逻辑读等)变成只需要耗费20%的CPU,这当然是好事儿。
    我的意思只是说,如果你看到CPU Time在Top 5事件中不需要去特意关注他,这个事件只是说CPU在Run,而其它的等待事件更能说明系统需要调整的地方。

  14. vecentli says:

    kamus on August 10, 2007 at 11:46 pm said:

    @木匠
    暂时还没有时间看你的awr,不过我会看的。gc cr grant 3-way是这样产生的,一个节点需求一个cr block,此时需要询问master,但是此block的master不在自己实例上,这样是一次网络hop,master发现这个block在另外的实例上,于是告诉另外那个实例把block传给这个请求的实例,这又是一次网络hop,另外的实例给这个实例一个lock(这是grant)让这个实例自己去从disk上读取block,这是第三次网络hop,整个这个过程就是3-way的gc cr grant,通常这个等待下面会跟随着一次磁盘I/O。

    按照这个说法,应该是4-way。
    获得block的node活通知gcs,它是新的holder。

    10g rac sg。

    🙂

  15. babyblue says:

    每次都能在kamus这里发现一些非常有帮助的东西

Leave a Reply to piner Cancel reply

Your email address will not be published. Required fields are marked *