네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study

1. MaxGauge Case Study
Copyrights 2006. EXEM CO., LTD. All Rights Reserved
1
네트웍 설정 오류로 인한
RAC 시스템 성능 저하 분석 사례
EXEM CO., LTD
www.ex-em.com
2006.06
RAC 시스템의 성능은 인터커넥터의 성능에 크게 의존하고 있다. 따라서 네트웍 설정 등의 오류로 인해
인터커넥터의 성능이 저하되는 경우에는 RAC 시스템 전체의 성능이 저하될 수 있다. 이번 Case Study에
서는, Oracle DBMS의 성능진단/분석 툴인 Maxgauge를 활용하여, 네트웍 설정 오류로 인한 RAC 성능 저
하 문제의 원인을 규명해 보고자 한다.
본 사례에서 사용한 문제원인분석의 Flow(Performance Analyzer / MaxGauge)
Drill-Down Flow Menu & Data
1. 성능저하구간의 확인 [Trend Analysis] 화면에서 성능 저하 구간 확인
2. 대기이벤트의 검출 및 분석
[Trend Analysis]와 [Session List] 메뉴에서, 문제원인이
되는 대기이벤트를 탐색하고, 그 내용을 분석
3. 대기이벤트 발생원인의 조사
[Trend Analysis] 메뉴에서, 인터커넥터와 관련된 STAT
지표 및 대기이벤트의 추이를 분석
4. 네트웍 설정상의 오류 확인
STAT 및 대기이벤트에 기반한 오류 추론 및 시스템
차원의 검증 작업

2. MaxGauge Case Study
시스템 개요
항 목 내 용
O/S HP-UX 11.23 Itanium
Oracle Version 10.1.0.4
RAC 여부 3 Node(DBPA1, DBPA2, DBPA3)
Interconnect 10G Ethernet
1. 성능저하구간의 확인(DBPA1 인스턴스)
RAC 성능 문제를 분석하기 위해 RAC와 관련된 대기이벤트인 gc cr multi block request, gc cr block 2-way 이벤트
대기시간과 gc CPU used by this session 통계값을 분석하면, 아래와 같이 11시30분 ~ 16시30분 사이에 글로벌 캐
시와 관련된 성능 저하 현상이 발생한 것을 확인할 수 있다.
2. 대기이벤트의 검출 및 분석
성능 저하 현상의 원인을 규명하기 위해 문제 구간인 11시 30분 ~ 16시 30분 사이의 가장 대표적인 대기이벤
트는 gc cr multi block request 이벤트이다.
아래 그림은 문제 구간의 특정 세션(SID=1017)의 활동 상황을 시간 순으로 나열한 것이다. 하나의 멀티 블록
I/O 요청에 대해 19초 이상 응답을 받지 못하는 것을 확인할 수 있다.
Copyrights 2006. EXEM CO., LTD. All Rights Reserved
2

3. MaxGauge Case Study
3. 대기이벤트 및 STAT 상세 분석
문제 구간에서의 gc cr multi block request 대기 현상은 다음과 같은 특징을 지닌다.
대부분의 세션이 글로벌 캐시 관련 작업에서 대기 현상을 겪고 있다.
하나의 블록에 대한 요청에 대해 리모트 노드로부터 응답을 받는데 짧게는 5초, 길게는 40초 이상 대
기하고 있다.
하나의 블록에 대해 40초 이상 응답을 받지 못하고 있다는 것은 단순한 경합이나 혼잡이 아닌, 네트웍 설정
문제와 같은 하드웨어적인 오류가 문제의 원인임을 암시한다. 네트웍 하드웨어 설정에 문제가 있을 경우에는
네트웍 패킷이 정상적으로 전달되지 못해, 블록 전송 시에 유실이 발생할 수 있다. 이 경우 gc blocks lost 통계
값이 증가한다. 아래 그림은 문제 구간의 gc blocks lost, cluster wait time 통계값과 gc cr multi block request 이벤트
대기를 비교한 것이다.
Copyrights 2006. EXEM CO., LTD. All Rights Reserved
3

4. MaxGauge Case Study
위의 값들로부터 다음과 같은 사실들을 확인할 수 있다.
gc cr multi block request 대기가 증가하는 구간에 cluster wait time 통계값이 동일한 패턴으로 증가한다.
cluster wait time 통계값이 높은 구간에서 gc blocks lost 통계값이 크게 증가하는 것을 확인할 수 있다.
4. 문제 원인의 규명
gc blocks lost 통계값이 증가한다는 것은 물리적으로 네트웍상에서 블록 유실이 발생하고 있다는 것을 의미한다.
RAC에서의 블록 유실 현상은 대부분 하드웨어적인 오류에 의해서 발생한다.
문제가 발생한 이후 인터커넥터 즉, 네트웍과 관련된 설정 내용을 검증했으며, 다음과 갈은 사실을 확인할 수
있었다.
현재 네트웍 장비는 장애 시 즉시 복구를 위해 이중화되어 있다. 즉 Active Line과 Idle Line 두 개의
라인이 설정되었으며 평상시에는 Active Line만 사용하다가, 네트웍 장애 발생시 Idle Line을 사용하게
된다.
네트웍 설정을 검증한 결과 Idle 상태로 설정되어야 할 특정 Line이 Active 상태로 설정된 것이 확인
되었다.
이로 인해 Idle Line으로 블록이 전송되는 현상이 발생했으며, Oracle 프로세스가 블록 전송을 받지 못
하는 현상이 생겼다.
즉 성능 저하의 근본적인 원인은 인터커넥터를 구성하는 네트웍 장비의 설정상의 오류였음을 확인할 수 있다.
네트웍 설정의 오류로 인해 인터커넥터 성능 저하가 생기고, 이로 인해 RAC 시스템의 전반적인 시스템이 크
게 저하된 것이다.
Copyrights 2006. EXEM CO., LTD. All Rights Reserved
4

5. MaxGauge Case Study
5. 결론
성능 저하 현상
(gc cr multi block request 대기 및 gc block lost 통계값 증가)
네트웍 설정의 오류를 제거함
잘못된 네트웍 설정에 의한 패킷 유실 발생
Copyrights 2006. EXEM CO., LTD. All Rights Reserved
5