gc current block busy和LMS优先级

 

什么是gc current block busy

gc current block busy 等待是RAC中global cache全局缓存当前块的争用等待事件，该等待事件时长由三个部分组成：

 

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

 

Pin time = (time to read the block into cache) + (time to modify/process the buffer)

Busy time = (average pin time) * (number of interested users waiting ahead of me)

gc current block flush time

The current block flush time is part of the service (or processing) time for a current block. The pending redo needs to be flushed to the log file by LGWR before LMS sends it. The operation is asynchronous in that LMS queues the request, posts LGWR, and continues processing. The LMS would check its log flush queue for completions and then send the block, or go to sleep and be posted by LGWR. The redo log write time and redo log sync time can influence the overall service time significantly.

 

flush time 是Oracle为了保证Instance Recovery实例恢复机制，而要求每一个current block在本地节点local instance被修改后(modify/update) 必须要将该current block相关的redo 写入到logfile 后（要求LGWR必须完成写入后才能返回)，才能由LMS进程传输给其他节点使用。

 

而gc buffer busy acquire/release 往往是 gc current block busy的衍生产品， 当同一实例内的 多个进程并发地访问同一个数据块时 ， 首先发起的进程将进入 gc current block busy的等待 ，而在 buffer waiter list 上的后续进程 会陷入gc buffer busy acquire/release 等待

 

可以通过 设置_cr_server_log_flush =false(LMS are/is waiting for LGWR to flush the pending redo during CR fabrication. Without going too much in to details, you can turn off the behaviour by setting   _cr_server_log_flush to false.)

来禁止cr server flush redo log，但是该参数对于current block的flush time无效， 也强烈不推荐使用。

 

http://t.askmaclean.com/thread-438-1-1.html

 

For CR blocks, if the buffer is NOT busy, LMS process can send block immediately.

For CR blocks, if the buffer is busy, LMS process waits for Log flush to complete.

For CURRENT blocks, LMS process waits for log flush to complete.

 

GC CR latency ~=

Time spent in sending message to LMS +

LMS processing +

LGWR latency ( if any) +

Wire latency

 

GC CUR latency ~=

Time spent in sending message to LMS +

LMS processing : Pin block +

LGWR latency: Log flush +

Wire latency

 

http://www.orainternals.com/wp-content/uploads/2011/12/Riyaj_Battle_of_nodes_RAC_perf_myths_ppt.pdf

 

 

 

_high_priority_processes

10203引入此参数

_high_priority_processes调整进程优先级，在102和11g种LMS/VKTM为默认

 

NAME                                               VALUE                     ISDEFAULT ISMOD      ISADJ

-------------------------------------------------- ------------------------- --------- ---------- -----

_high_priority_processes                     LMS*|VKTM              TRUE      FALSE      FALSE

_os_sched_high_priority                      1                      TRUE      FALSE      FALSE

 

_high_priority_processes:

Default value: LMS*|VKTM*

This parameter controls what background processes should get Real time priority. Default is all LMS processes and VKTM process.

_os_sched_high_priority :

Default value: 1

This is a switch. If set to 0, no background process will run in high priority.

http://www.orainternals.com/wp-content/uploads/2011/12/Riyaj_Battle_of_nodes_RAC_perf_myths_ppt.pdf

 

可以看到lms/vktm进程优先级较高，其linux进程级别为RR，而LGWR为TS

$ ps -eo pid,class,pri,nice,time,args | egrep 'lms|vktm' | grep -v grep

PID CLS PRI  NI     TIME COMMAND

18749 RR   41   - 23:09:40 asm_vktm_+ASM1

18779 RR   41   - 05:35:13 asm_lms0_+ASM1

26376 RR   41   - 18:45:34 ora_vktm_USSOAP1

26415 RR   41   - 1-00:02:47 ora_lms0_USSOAP1

26421 RR   41   - 1-00:20:38 ora_lms1_USSOAP1

_$  ps -eo pid,class,pri,nice,time,args | egrep lgwr

PID CLS PRI  NI     TIME COMMAND

 9655 TS   19   0 00:00:00 egrep lgwr

18797 TS   19   0 00:05:39 asm_lgwr_+ASM1

26451 TS   19   0 10:58:43 ora_lgwr_USSOAP1

http://kerryosborne.oracle-guy.com/2010/03/increasing-priority-of-lgwr-process-using-_high_priority_processes/

 

 

linux进程优先级

How to find out the scheduling class of a process.

# ps  command with “class” flag

#   TS  SCHED_OTHER (SCHED_NORMAL)

#   FF  SCHED_FIFO

#   RR  SCHED_RR

 

linux进程调动方法

1，SCHED_OTHER 分时调度策略，

2，SCHED_FIFO实时调度策略，先到先服务

3，SCHED_RR实时调度策略，时间片轮转

实时进程将得到优先调用，实时进程根据实时优先级决定调度权值，分时进程则通过nice和counter值决定权值，nice越小，counter越大，被调度的概率越大，也就是曾经使用了cpu最少的进程将会得到优先调度。

SHCED_RR和SCHED_FIFO的不同：

当采用SHCED_RR策略的进程的时间片用完，系统将重新分配时间片，并置于就绪队列尾。放在队列尾保证了所有具有相同优先级的RR任务的调度公平。

SCHED_FIFO一旦占用cpu则一直运行。一直运行直到有更高优先级任务到达或自己放弃。

 

http://baike.baidu.com/view/1380355.htm

 

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

转载于:http://blog.itpub.net/15480802/viewspace-760699/