태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Oracle 10g RAC - ASSM으로 인한 성능 저하 현상 사례

오라클 2007.08.21 16:32
얼마전 고객사의 특정 환경에서 실제로 발생했던 사례를 바탕으로 ASSM(Automatic Segment Space Management)에서 발생한 성능 저하 현상에 대해 알아보고자 한다.

문제가 발생한 환경과 상황은 아래와 같다.
  • 두 개의 Insance로 이루어진 RAC 환경이며
  • Oracle 버전은 10.2.0.2
  • 모든 테이블스페이스는 ASSM을 사용
  • 양 쪽 Instance에서 각각 동일 테이블에 대해 많은 수의 프로세스가 동시에 대량의 Insert 작업을 수행


오라클의 성능 문제와 Wait Event 분석 기법에 대해 지식을 가지고 있는 사람이라면 이런 상황에서 다음과 같은 예측을 할 수 있을 것이다.
  1. 대량의 Insert가 발생하므로 HWM(High Water Mark)의 빈번한 이동이 예상된다. 따라서 enq: HW - contention 이벤트가 목격될 것이다.
  2. 동시에 동일 테이블에 대해 Insert를 수행하므로 테이블 블록에 대해 buffer busy waits(class=1) 이벤트가 목격될 것이다.
  3. 만일 테이블에 인덱스가 있다면 인덱스 분할(Index Split)에 의한 enq: TX - index contention 이벤트가 발생할 것이다.
위의 대기 이벤트들이 대량 Insert 작업에 가장 흔히 목격되는 이벤트들이다. 만일 전문가적인 지식을 갖춘 사람이라면 enq: FB - contention 이벤트를 이야기할 수도 있을 터이다.
(참조)
enq: FB - contention 이벤트는 FB 락을 획득하는 과정에서 경합이 발생한다는 것을 의미한다. FB 락은 ASSM에서 사용되는 락으로 ASSM으로 관리되는 세그먼트에 대해 블록 포맷팅을 수행하는 과정을 보호하기 위해 사용된다.

하지만, 이번 환경에서는 특이하게도 L1BMB에 대해 gc buffer busy 이벤트가 과도하게 발생하는 것이 목격되었다.

gc buffer busy 이벤트는 버퍼가 글로벌한 경합을 겪는다는 것을 의미한다. 즉, Instance1이 특정 버퍼를 변경하고자 하는데, 현재 이 버퍼가 다른 Instance의 요청에 의해 전송되고 있는 중이거나, 전송받고 있는 중이라면 이 전송작업이 끝날 때까지 기다려야 한다. 이때 보고되는 대기 현상이 바로 gc buffer busy 이벤트이다.

이 대기 현상을 특이하다고 말하는 것은 다음과 같은 이유에서이다.
  • 문제가 되는 세그먼트는 ASSM을 사용한다. ASSM을 사용하는경우, 오라클은 L1BMB에 대해 소유 인스턴스(Owning Instance)를 지정한다.
  • 즉, 특정 Instance가 Insert를 하기 위해 Free Block을 필요로 하는 경우 우선 자신이 소유한 L1BMB만을 사용한다.
  • 하나의 L1BMB는 16개 ~ 1024개의 데이터 블록을 관리한다.
  • 따라서 이론적으로는 RAC에서는 Insert 작업시에는 노드 간의 데이터 전송이 불필요하다.
즉, ASSM을 사용하는 RAC 환경에서는 각 Instance가 별도의 Free Block을 할당받기 때문에 Insert 작업에 의한 글로벌 버퍼 교환이 최소화되어야 정상이다.

그럼에도 불구하고 이 환경에서는 L1BMB에 대한 gc buffer busy 이벤트 대기 현상이 광범위하게 발생하고 있는 것이다.

이것은 (아마도) Soft Affinity 현상에 의한 것으로 생각된다. Soft Affinity란 각 Instance가 소유한 L1BMB의 소유주를 바꾸는 현상을 의미한다. 다음과 같은 경우를 가정해보자. Instance1이 특정 세그먼트에 대해 계속적인 Insert 작업을 수행하는데 반해, Instance2번은 Insert 작업을 거의 수행하지 않는다. 이 경우 Instance2번이 소유한 L1BMB는 무용지물이 된다. 이런 경우 오라클은 Instance2번이 소유한 L1BMB를 Instance1번에 양보한다. 즉 Hard하게 결정된 Affinity를 Soft하게 재부여한다. 이 기능을 가리켜 흔히 Soft Affinity를 부여한다고 말한다.

즉, 이번 운영 환경에서 L1BMB에 대해 gc buffer busy 이벤트가 광범위하게 발생한 것은 양쪽 노드의 동시 Insert 작업에 의해 L1BMB의 주인(Owner)가 계속적으로 바뀌는 현상이 발생하고 이로 인해 L1BMB를 계속적으로 주고 받는 현상이 발생했기 때문으로 이해할 수 있다.

하지만, 이런 행동 양식이 오라클의 원래 작동 방식인지 아니면 버그나 잘못된 파라미터 설정에 의한 것인지는 확실하지 않다.

마지막으로 질문을 하나 던질 필요가 있겠다. 문제가 발생하는 이유에 대해 나의 추측이 맞다면 해결책은 무엇일까?
  • 우선, ASSM을 사용하면서 Soft Affinity를 사용하지 않은 방안이 있을까? 불행하게도 불가능한 것으로 보인다.
  • 그렇다면 최후의 해결책은 FLM(Free List Management)를 사용하는 것이다. FLM은 매우 무식하고 단순한 방법이라서 Affinity를 동적으로 변경하는 작업 자체가 발생하지 않기 때문이다.
이 글을 읽는 여러분의 생각은 어떤가?

PS) HWM 경합, FB 락 경합, RAC에서의 글로버 버퍼 경합에 대해 생소한 사람이라면 반드시 아래 두 개의 책을 읽어 보기 바란다. 내가 지은 책이라서가 아니라, 이런 이슈에 대해 상세히 설명한 유일한 책들(국내에서는)이기 때문이다. ^^


OWI Advanced Oracle Wait Interface in 10g

조동욱

엑셈 2006.05.08







신고
Trackback 0 : Comments 2
  1. 애독자 2007.08.21 19:43 신고 Modify/Delete Reply

    덧글 달기 조심스럽긴 합니다만 soft affinity 변경을 DRM(Dynamic Resource reMastering) 으로 간주한다면 _gc_affinity_time=0 으로 설정해 DRM 을 막을 수 있진 않을까 합니다.

  2. 욱짜 2007.08.21 20:47 신고 Modify/Delete Reply

    반갑습니다. Soft Affinity는 DRM과는 관련이 없는 거 같습니다. DRM은 런타임에 동적으로 데이터 블록(혹은 세그먼트)의 마스터 노드(Master Node)를 변경하는 것인데 반해 Soft Affinity는 L1BMB의 물리적인 소유주(Owining Instance)를 변경하는 것이거든요.

Write a comment

티스토리 툴바