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
显然,增加_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/