Gc cr/current multi block request

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[편집] Basic Info

로컬 캐시에 존재하지 않는 여러 개의 데이터 블록을 동시에 읽고자 하는 프로세스는, 해당 데이터 블록들을 관리하는 마스터 노드에게 블록 전송을 요청하고, 응답을 받을 때까지 gc cr multi block request 이벤트나 gc current multi block request 이벤트를 대기한다.

gc cr/current request 이벤트가 싱글 블록 I/O에 의해 발생하는 반면, gc cr/current multi block request 이벤트는 멀티 블록 I/O에 의해 발생한다. 따라서 gc cr/current request 이벤트는 db file sequential read 이벤트와 유사한 속성을 지니고, gc cr/current multi block request 이벤트는 db file scattered read 이벤트와 유사한 속성을 지닌다.

FTS(Full Table Scan)와 같은 멀티 블록 I/O를 수행하고자 하는 서버 프로세스는 마스터 노드에게 DB_FILE_MULTIBLOCK_READ_COUNT 파라미터 값만큼 블록 전송 요청을 수행하며, 블록을 전송 받거나 블록을 읽을 권한을 부여 받는다. 아래 테스트 결과를 보자. DB_FILE_MULTIBLOCK_READ_COUNT 값에 의해 블록 전송이 어떤 영향을 받는지 알 수 있다.

-- 멀티 블록에 의한 I/O 수를 8로 변경
SQL> ALTER SESSION SET DB_FILE_MULTIBLOCK_READ_COUNT = 8;
-- 멀티 블록 I/O 수행
SQL> SELECT COUNT(*) FROM multi;
…
-- SQL*Trace를 통해 대기 이벤트 확인
-- 8번의 gc cr multi block request 이벤트 대기 후 db file scattered read 이벤트를 대기한다.
-- 즉, 블록을 읽을 권한을 부여 받았음을 의미한다.
WAIT #1: nam='gc cr grant 2-way' ela= 285 p1=14 p2=29470 p3=4
WAIT #1: nam='db file sequential read' ela= 1098 p1=14 p2=29470 p3=1
WAIT #1: nam='gc cr multi block request' ela= 553 p1=14 p2=29478 p3=1
WAIT #1: nam='gc cr multi block request' ela= 27 p1=14 p2=29478 p3=1
WAIT #1: nam='gc cr multi block request' ela= 3 p1=14 p2=29478 p3=1
WAIT #1: nam='gc cr multi block request' ela= 30 p1=14 p2=29478 p3=1
WAIT #1: nam='gc cr multi block request' ela= 4 p1=14 p2=29478 p3=1
WAIT #1: nam='gc cr multi block request' ela= 16 p1=14 p2=29478 p3=1
WAIT #1: nam='gc cr multi block request' ela= 13 p1=14 p2=29478 p3=1
WAIT #1: nam='gc cr multi block request' ela= 3 p1=14 p2=29478 p3=1
WAIT #1: nam='db file scattered read' ela= 7976 p1=14 p2=29471 p3=8
WAIT #1: nam='gc cr multi block request' ela= 539 p1=14 p2=29486 p3=1
WAIT #1: nam='gc cr multi block request' ela= 27 p1=14 p2=29486 p3=1
…
(오라클 10g R1에서는 한번의 멀티 블록 I/O에서 요청하는 블록수만큼 gc cr multi block request 대기가 반복적으로 발생하지만, 오라클 10g R2에서는 한번의 멀티 블록 I/O 요청에 대해 gc cr multi block request 대기는 한번만 발생한다. 이는 멀티 블록 I/O 처리 메커니즘이 개선되었다는 것을 의미한다)

gc cr multi block request 이벤트는 CR 모드의 멀티 블록 I/O에 의해 발생한다. CR 모드의 멀티 블록 I/O는 읽기 목적, 즉 SELECT에 의한 FTS나 IFFS(Index Fast Full Scan) 등에서 발생한다. 반면, gc current multi block request 이벤트는 Current 모드의 멀티 블록 I/O에 의해 발생한다. 대표적인 사례는 FTS를 통한 Update나 Delete 작업 그리고 Insert 작업을 위해 새로운 데이터 블록을 읽어오는 경우이다. 아래 예를 통해 Insert 작업과 gc current multi block request 대기 이벤트의 관계를 알 수 있다.

-- Insert 수행
SQL> INSERT INTO multi VALUES(1, ‘TEST’);
…
-- 16번(DB_FILE_MULTIBLOCK_READ_COUNT)의 gc current multi block request 대기 이후 db file scattered read 이벤트를 대기한다.
-- 즉, 멀티 블록을 Current 모드로 직접 읽을 권한을 부여 받았음을 알 수 있다.
WAIT #2: nam='gc current grant 2-way' ela= 298 p1=14 p2=29451 p3=33619976
WAIT #2: nam='gc current multi block request' ela=6 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=35 p1=4 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=12 p1=4 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=6 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=5 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=4 p1=4 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=7 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=4 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=0 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=4 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=2 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=3 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=2 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=7 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=4 p1=14 p2=29630 p3=33554446
WAIT #2: nam='gc current multi block request' ela=3 p1=14 p2=29630 p3=33554446
WAIT #2: nam='db file scattered read' ela= 16045 p1=14 p2=29615 p3=16
…

Current 모드의 멀티 블록 I/O 요청에서 한 가지 주의할 점은, 항상 16개의 블록 단위로 멀티 블록 I/O를 수행한다는 것이다. CR 모드의 멀티 블록 I/O는 DB_FILE_MULTIBLOCK_READ_COUNT 파라미터로 한번에 처리되는 블록 수를 제어할 수 있지만, Insert 작업에 의한 Current 모드의 멀티 블록 I/O는 파라미터의 값과 무관하게 항상 16 블록 단위로 작업이 이루어진다.

gc cr/current multi block request 이벤트에 대한 대기를 해소하는 방법은 기본적으로 gc cr/current request 이벤트와 동일하다. 단, 멀티 블록 전송에 의한 네트워크 부하 발생이 가능하기 때문에 네트워크 설정과 한번에 전송 요청하는 블록의 수의 적정치를 고려할 필요가 있다.

[편집] gc cr multi block request 이벤트와 요청 블록의 수

앞서 언급한 것처럼 CR 모드의 멀티 블록 전송 요청에서는 항상 DB_FILE_MULTIBLOCK_READ_COUNT 파라미터 값만큼의 블록 수를 동시에 요청한다. 지나치게 많은 블록을 동시에 요청하면 요청과 응답 메시지의 크기가 커져서 작업이 지연되는 현상이 발생할 수 있다. 특히 gc cr multi block request 이벤트의 타임 아웃(Time Out)회수가 높게 나온다면 현재 네트워크 설정으로는 많은 수의 블록 요청을 동시에 처리할 수 없다는 것을 암시한다. 이런 경우에는 DB_FILE_MULTIBLOCK_READ_COUNT 파라미터의 값을 낮추는 것을 고려할 필요가 있다. 경우에 따라서 8이나 4와 같은 낮은 값을 사용해도 무방하다.

[편집] gc cr multi block request 이벤트와 네트워크 설정

MTU 크기를 크게 하면 하나의 패킷에 많은 양의 메시지를 담을 수 있기 때문에 멀티 블록 I/O 요청에 더 유리하다. 대량의 멀티 블록 I/O 요청을 효율적으로 처리하기 위해서는 큰 크기의 UDP Receive 버퍼가 필수적이다. 만일 인터커넥트에서 잦은 패킷 유실이 발생한다면 더욱 그러하다. 오라클은 기본적으로 OS에서 설정한 버퍼 크기를 사용하며, 최소값으로 128K 바이트를 사용한다. 가능한 256K 바이트 이상의 UDP 버퍼 크기를 사용하고, 필요하다면 수 메가 바이트 정도의 크기를 사용하는 것도 고려해 볼 수 있다.

[편집] Parameter & Wait Time

[편집] Wait Parameters

gc cr/current multi block request 대기이벤트의 대기 파라미터는 다음과 같다.

P1 : File#

P2 : Block#

P3 : Class#

[편집] Wait Time

[편집] Check Point & Solution

[편집] Event Tip

[편집] Analysis Case

RAC 시스템의 성능은 인터커넥터의 성능에 크게 의존하고 있다. 따라서 네트웍 설정 등의 오류로 인해 인터커넥터의 성능이 저하되는 경우에는 RAC 시스템 전체의 성능이 저하될 수 있다. Oracle DBMS의 성능진단/분석 툴인 Maxgauge(맥스게이지)를 활용하여, 네트웍 설정 오류로 인한 RAC 성능 저하 문제의 원인을 규명해 보고자 한다.

[편집] 성능저하구간의 확인

RAC 성능 문제를 분석하기 위해 RAC와 관련된 대기이벤트인 gc cr multi block request, gc cr block 2-way 이벤트 대기시간과 gc CPU used by this session 통계값을 분석하면, 아래와 같이 11시30분 ~ 16시30분 사이에 글로벌 캐시와 관련된 성능 저하 현상이 발생한 것을 확인할 수 있다. 그림:Case1_1.jpg

[편집] 대기이벤트의 검출 및 분석

성능 저하 현상의 원인을 규명하기 위해 문제 구간인 11시 30분 ~ 16시 30분 사이의 가장 대표적인 대기이벤트를 확인해 보면 gc cr multi block request 이벤트이다. 그림:Case1_2.jpg

아래 그림은 문제 구간의 특정 세션(SID=1017)의 활동 상황을 시간 순으로 나열한 것이다. 하나의 멀티 블록 I/O 요청에 대해 19초 이상 응답을 받지 못하는 것을 확인할 수 있다. 그림:Case1_3.jpg

[편집] 대기이벤트 및 STAT 상세 분석

문제 구간에서의 gc cr multi block request 대기 현상은 다음과 같은 특징을 지닌다.

대부분의 세션이 글로벌 캐시 관련 작업에서 대기 현상을 겪고 있다. 하나의 블록에 대한 요청에 대해 리모트 노드로부터 응답을 받는데 짧게는 5초, 길게는 40초 이상 대기하고 있다.

하나의 블록에 대해 40초 이상 응답을 받지 못하고 있다는 것은 단순한 경합이나 혼잡이 아닌, 네트웍 설정 문제와 같은 하드웨어적인 오류가 문제의 원인임을 암시한다. 네트웍 하드웨어 설정에 문제가 있을 경우에는 네트웍 패킷이 정상적으로 전달되지 못해, 블록 전송 시에 유실이 발생할 수 있다. 이 경우 gc blocks lost 통계값이 증가한다.

아래 그림은 문제 구간의 gc blocks lost, cluster wait time 통계값과 gc cr multi block request 이벤트 대기를 비교한 것이다. 그림:Case1_4.jpg

위의 값들로부터 다음과 같은 사실들을 확인할 수 있다.

▣ gc cr multi block request 대기가 증가하는 구간에 cluster wait time 통계값이 동일한 패턴으로 증가한다.

▣ cluster wait time 통계값이 높은 구간에서 gc blocks lost 통계값이 크게 증가하는 것을 확인할 수 있다.

[편집] 문제 원인의 규명

gc blocks lost 통계값이 증가한다는 것은 물리적으로 네트웍상에서 블록 유실이 발생하고 있다는 것을 의미한다. RAC에서의 블록 유실 현상은 대부분 하드웨어적인 오류에 의해서 발생한다.

문제가 발생한 이후 인터커넥터 즉, 네트웍과 관련된 설정 내용을 검증했으며, 다음과 갈은 사실을 확인할 수 있었다.

현재 네트웍 장비는 장애 시 즉시 복구를 위해 이중화되어 있다. 즉 Active Line과 Idle Line 두 개의 라인이 설정되었으며 평상시에는 Active Line만 사용하다가, 네트웍 장애 발생시 Idle Line을 사용하게 된다. 네트웍 설정을 검증한 결과 Idle 상태로 설정되어야 할 특정 Line이 Active 상태로 설정된 것이 확인되었다. 이로 인해 Idle Line으로 블록이 전송되는 현상이 발생했으며, Oracle 프로세스가 블록 전송을 받지 못하는 현상이 생겼다.

즉 성능 저하의 근본적인 원인은 인터커넥터를 구성하는 네트웍 장비의 설정상의 오류였음을 확인할 수 있다.

네트웍 설정의 오류로 인해 인터커넥터 성능 저하가 생기고, 이로 인해 RAC 시스템의 전반적인 시스템이 크게 저하된 것이다.

[편집] 결론

gc cr multi block request 대기 및 gc block lost 통계값 증가 ☞ 잘못된 네트웍 설정에 의한 패킷 유실 발생 ☞ 네트웍 설정의 오류를 제거하여 해결