h3.2.7 LMS 프로세스의 부하
LMS는 요청 노드의 블록 전송 요청을 인터커넥트를 사용하여 처리하는 프로세스로 즉 인터커넥트를 사용하여 I/O작업을 한다고 볼 수 있다. 이 LMS는 CPU를 많이 사용하는 프로세스로 DBA는 LMS 프로세스가 CPU 자원을 효율 적으로 사용할 수 있도록 보장해 주는 것이 좋다.
CPU 리소스가 충분한 경우 다음과 같은 방법으로 LMS 프로세스 부하를 처리할 수 있다.

• 프로세스 개수 변경
• 우선순위 조정
• 우선순위 스케쥴링 방식 변경

h4.2.7.1 프로세스 개수 변경
다음의 파라메터를 사용하여 LMS 프로세스의 개수를 조정한다.

GCS_SERVE_PROCESSES
LMS의 프로세스 개수를 설정하는 파라메터이다.

권고치는 4개의 CPU당 하나의 LMS 프로세스{}를 할당하는 것이며 최소값은 2개이다. 동기화 작업이 많은 극단적인 시스템 이라면 1~2개의 CPU당 하나의 LMS 프로세스를 할당하는 것도 가능하다.

h4.2.7.2 우선 순위 조정
LMS의 CPU 자원을 보장하기 위해 LMS의 우선순위를 높혀주는 것도 방법 중 하나이다. 이때 renice 명령을 사용한다.

NICE
프로세스가 다른 프로세스에 작업 순서를 양보하는 수치를 말한다. 즉, NICE 값이 낮으면 CPU사용에 대한 순서를 양보하지 않게 되고, 높으면 높을수록 많이 양보하게 된다. 이 값은 +19~-20{}사이의 값을 가진다. 일반 프로세스는 0{}값을 가진다.
CPU 경쟁이 높은 시스템의 경우 -20까지 낮추는 것이 좋다.

확인 방법
다음과 같이 현재 사용하는 LMS 프로세스를 확인할 수 있다.
[root@rac02~]# ps -efl | grep lms

renice 사용법
다음과 같이 NICE값을 낮출 수 있다.
[root@rac02~]# renice -20 -p 7991 7993
7991, 7993 프로세스의 NICE값을 -20으로 변경한다.

h4.2.7.3 우선 순위 스케쥴링 방식 변경
CPU의 자원할당은 시분할(Time Sharing) 스케쥴링을 사용하여 처리한다. 이것을 실시간 스케쥴링 기법{}을 사용하여 처리하게 하는것이다.

시분할 스케쥴링 방법
프로세스의 우선순위를 참조하여 프로세스를 실행 -> 일정 시간동안 프로세스 실행 -> 다음번 프로세스 실행

실시간 스케쥴링 방법
특정 프로세스가 특정 작업을 수행하는데 항상 일정한 응답 시간{}을 보장 받는 방법으로 Real-Time OS에서 대단히 중요한 개념이다. 실시간 스케쥴링을 사용하는 프로세스의 경우 그 특징(일정한 응답시간)으로 인해 고정된 우선순위{}를 받으며 시분할 기법에 비해 높은 우선 순위{}를 받는다.

_OS_SCHED_HIGH_PRIORITY
오라클 10g R2 부터는 _OS_SCHED_HIGH_PRIORITY 파라메터를 사용하여 LMS 프로세스는 실시간 스케쥴링을 사용하도록 설정되어있다.

높은 값을 부여하면 부여할수록 더 높은 우선 순위를 부여받는다.

h3.2.8 LGWR/DBWR 프로세스의 부하
LGWR와 DBWR는 RAC 환경에서도 매우 중요한 일을 담당한다.

h4.2.8.1 LGWR
LGWR는 RAC환경 하에서 블록 전송 과정에서 Redo Flush{}를 담당한다.
LGWR에 작업 미비 -> Redo Flush 지연 -> gc cr/current request 증가

Redo Flush
로컬 캐쉬의 Dirty Block을 remote로 전송하기 전에 Dirty Block에 해당하는 Redo 데이터를 Redo Log로 저장하는 작업을 말함.

h4.2.8.2 DBWR
DBWR는 RAC환경 하에서 Fusion Write 기능을 담당한다.
DBWR 작업 미비 -> Fusion Write 지연 -> gc cr/current block reqeust 증가

Fusion Write
다음의 일련의 메커니즘을 Fusion Write라고 한다.

[그림 2-1] Fusion Write 메커니즘

h3.2.9 gc cr/current request의 Fixed-up 이벤트들
gc cr/current request들은 앞에서 설명한 대로 Placeholder 이벤트로 어떤 결과로 응답을 받았느냐에 따라 Fixed-up 이벤트가 결정된다.

같은 gc cr request라 할 지 라도 Fixed-up 이벤트가 어떤 것이냐에 따라 원인 및 해결책이 달라지므로, Fixed-up 이벤트도 자세히 살펴봐야 한다.