Tuning Global Cache - Expert Oracle RAC Performance Diagnostics and Tuning - page 398

Lack of CPU resources, or when there are several high consumers for CPU resources on the servers, could directly
impact GCS and GES activities including allocation of latches to complete these activities.
LMS processes request one operation at a time. Only after completing one request will it attempt the next
request. This means if LMS functions are delayed, there could be queuing on requests, causing overall slow response
times on the RAC database. However, multiple LMSs can operate in parallel.
High latency numbers experienced during the prepare phase discussed previously could have several reasons,
such as CPU starvation, scheduling delays, and high run queue lengths affecting the LMS processes and the
foregrounds waiting for response from an LMS. Starting with Oracle Database Version 10.2.0.3, Oracle has changed
the priority of the LMS processes. In the process output following, the LMS is running at the RR (round robin) class
and at a higher priority compared to the time-sharing ( TS) class that the other background processes use.
[oracle@prddb1 ~]$ ps -flcae | egrep "TTY|_l"
F S UID PID PPID CLS PRI ADDR SZ WCHAN STIME TTY TIME CMD
0 S oracle 5104 2346 TS 21 - 15290 pipe_w 13:21 pts/0 00:00:00 egrep TTY|_l
0 S oracle 15763 1 TS 24 - 120911 - Nov13 ? 00:00:21 asm_lmon_+ASM7
0 S oracle 15765 1 TS 24 - 123040 624857 Nov13 ? 00:01:06 asm_lmd0_+ASM7
0 S oracle 16713 1 RR 41 - 122912 624857 Nov13 ? 00:00:01 asm_lms0_+ASM7
0 S oracle 16719 1 TS 21 - 119072 - Nov13 ? 00:00:00 asm_lmhb_+ASM7
0 S oracle 16736 1 TS 24 - 119935 - Nov13 ? 00:00:00 asm_lgwr_+ASM7
0 S oracle 16779 1 TS 24 - 119338 624840 Nov13 ? 00:00:00 asm_lck0_+ASM7
0 S oracle 19810 1 TS 24 - 18537705 156203 Nov13 ? 00:03:44 ora_lmon_PRD_1
0 S oracle 19812 1 TS 24 - 18538806 624857 Nov13 ? 00:05:44 ora_lmd0_PRD_1
0 S oracle 19817 1 RR 41 - 18540918 - Nov13 ? 00:04:27 ora_lms0_PRD_1
0 S oracle 19821 1 RR 41 - 18541434 - Nov13 ? 00:04:31 ora_lms1_PRD_1
0 S oracle 19827 1 TS 24 - 18534262 - Nov13 ? 00:00:00 ora_lmhb_PRD_1
0 S oracle 19835 1 TS 24 - 18540697 - Nov13 ? 00:00:44 ora_lgwr_PRD_1
0 S oracle 19892 1 TS 24 - 18537087 969103 Nov13 ? 00:05:24 ora_lck0_PRD_1
Starting with Oracle Database 11g Release 2, the LMS and VKTM (virtual keeper of time) background processes
are set internally 4 to run at high priority.
Almost always, a good step to look at the reasons for resource contention is to look at the Oracle wait interface
using GV$SYSTEM_EVENT , GV$SESSION_EVENT , GV$SESSION_WAIT, GV$SESSION_WAIT_HISTOGRAMS , and GV$EVENT_NAME ;
Any wait event that ends with the word “congestion” implies that the LMS is very busy or starving for CPU. Scheduling
delays and CPU starvation for shadow processes can be recognized statistically.
Transfer Phase
Similar to the prepare latency, we also need to compute the transfer latency to determine what part of the round trip is
slowing down the system. The transfer latency is computed as follows:
Transfer latency = Interconnect latency - prepare latency
4 Setting of the LMS to run at this priority class is driven by the underscore parameter _HIGH_PRIORITY_PROCESSES , and the values
are set to LMS | VKTM . VKTM (Virtual Time Keeper) is a new background process introduced in Oracle Database 11g Release 2 and
manages the time across the RAC cluster.