探索系列——神人steve adams之著oracle8i interal service(五）

  tuning the spin count调优spin的次数

  显然，增加_spin_count会提升spinning的效力，但这样会花费一些cpu time在不必要的spins上。其实调节spin count的问题就是
如可权衡spinning花费的cpu time与避免上下文切换节省的cpu time。这里有个法则，就是全力减少下面的值:
 _spin_count*sleeps/misses
这个公式就是spinning的成本.如果迷茫的话，就会加大spin count的值而不是选择一个更小的值。如果一个oracle instance,
发现轻微的latching问题，加大_spin_count会有好处。在一系列的cpu机器上，假如许多活动进程对于这些cpu的权重或重要性是一样的（优先级），如此配置非常有用.
但发现一个实例出现相当严重的latch竞争，最优的spin count通常应小于默认的spin count值，而不是大于它.
 调节spin count你最好最后作，当你尝试节所有的方法（比如找到latch).


sleeps 沉睡
  假如一个乐观等待latch失败，此时在这个进程沉睡之前，它必须安排再次醒来的一些事情。对于马上沉睡（再次醒来）的一个进程，有两种机制。latch sleeps的正常机制就是超时。
一个进程会沉睡，在latch等待一个信号量，但在这样作之前，它要设置一个alarm，用此在指定的间隔时间最后发出一个信号.所指定的这个间隔是一个变量。随着再次get latches的失败，这个间隔值会加位增大.
这个间隔相关算法是由_max_exponential_sleep控制，在oracle8中默认是2 seconds.但是，哪果这个进程已经占用另一个latches,此时最大的沉睡时间减少为_max_sleep_holding_latch参数值,它默认为4 centiseconds,也可能根据这个进程所占用的其它一些latches会更少

   进程在沉睡之前，要作的的另一件事就是更新v$session_wait的会话等待信息，表明进程正在等待latch free事件完成

等待参数（latch free waits)

参数                                     描述
p1                                       所需latch的sga地址;查询v$latch_parent及child得到
p2                                       latch的类型，对应v$latch的latch#
p3                                       尝试得到一个latch之前，这个进程的沉睡次数



   如果一个进程以乐观或悲观模式get 一个latch再次失败的话，它会更新v$latch_misses latch misses统计信息.这个更新动作不被latch保护，因此这些统计信息可能并不完全与v$latch同步。v$latch_misses的每行记录一个latch可能从这个持有，nwfail_count及sleep_count列记录
no-wait get失败次数和沉睡次数.当持有一个特有位置的latch时，会发生这种情况.不幸的是，要相当精通了解用于解析分析这些统计重要性的oracle server 代码.



latch wait posting  这是另一种机制

  一个进程在get某个latch失败后，沉睡之前，可能再次被映射的第二种机制或方法叫作它.采用这种配置，free这个请求latch的另一个进程将映射这个沉睡的进程.
等待进程必须请求latch wait posting，在它准备沉睡之前。通过把自己的相关信息放入用于post的一系列进程列表之中（就是一个队列，可以这样理解）这样实现它.
就是叫作latch wait list.当一个进程free a latch,它会检查latch wait list,如果发现有一个进程在等待这个latch,它给这个等待进程发送相应的信号量.其实就相当于给os发一个信号，这个等待进程可以运行了

   这种机制的好处就是，等待进程获取latch的可能性更高，只要这个latch free掉.当然，对于它也有很大的成本，因为要维护latch wait list数据结构.这种数据结构是以在sga的进程表之简单（单向）链表方式来实现(我们看到就是x$ksupr.ksllalaq).当然，还有一些其它的数据结构，这些列表必须被latch保护。
如果发现在某个地方大量使用latch wait posting,那么latch wait list就会变得很大，导致latch wait list latch会长时间占有，比一般情况.实际上，发现二级latch wait list latch的竞争很正常,基本出现于开启latch wait posting机制，对于其它一些latch的严重竞争.

    默认latch wait posting只有要library cache和shared pool latches会开启.设置_latch_wait_posting为1就可以禁用它，或者值为2可以启用它.你调节这个值一定要三思.如library cache latch问题很严重，禁用它很有作用。但相反如果对于一些其它的latch竞争很中和，可以开启它，这样反而会提升性能.
甚至为所有的latch开启它时，latch wait posting不一定总会对于cache buffers chains latch请求进行沉睡.
    v$latch waiters_woken列，表示一个waiter通过latch wait posting机制，被唤醒的次数.这个统计值实际会大于misses的个数，因为会发生一个被post的进程，并没有得到latch,为何呢？原因就是在这个过程之中其它进程占用了这个latch.




36page

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

转载于:http://blog.itpub.net/9240380/viewspace-660133/