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無效， 也強烈不推薦使用。

 

 

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

 

 

 

 

_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.

 

可以看到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

 

 

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則一直執行。一直執行直到有更高優先順序任務到達或自己放棄。