DB2 튜닝 가이드 Part 7: 튜닝과 트러블슈팅(3) 메모리 병목

대부분의 DB2 시스템은 '성능 전개(performance evolution)' 과정을 거친다. 시스템을 배포한 후 시스템 모니터링을 하고, 만약 문제점이 발생되면 문제해결 과정을 거친다. DB2 튜닝 가이드는 단계별로 최상의 성능을 위한 최적의 설정을 제시함으로써, DB2 시스템 성능이 최상을 유지하도록 도와준다. 이번 회에서는 성능 튜닝과 트러블슈팅 과정 중 메모리 병목 상태에서의 해결 방안을 살펴본다.
<연재순서>
DB2 튜닝 가이드 - Part 1: 최상의 성능을 위한 시스템 구성
DB2 튜닝 가이드 - Part 2: 최상의 성능을 위한 DB 구성 (1)
DB2 튜닝 가이드 - Part 3: 최상의 성능을 위한 DB 구성 (2)
DB2 튜닝 가이드 - Part 4: 시스템 성능 모니터링
DB2 튜닝 가이드 - Part 5: 튜닝과 트러블슈팅(1) - 디스크 병목
DB2 튜닝 가이드 - Part 6: 튜닝과 트러블슈팅(1) - CPU 병목
DB2 튜닝 가이드 Part 7: 튜닝과 트러블슈팅(3) 메모리 병목

시스템 병목상태 > 메모리 병목상태

메모리가 충분하고 올바르게 구성되는 것은 최상의 시스템 성능에 있어 대단히 중요하다. 메모리가 적절하지 않을 경우 버퍼링된 데이터에 액세스하면 디스크 I/O로 전환되어 진행 중에 디스크 병목 상태를 발생시키는 경우가 많다. 뿐만 아니라 작지만 중요한 양의 메모리가 SQL 액세스 플랜, 잠금과 같은 메타데이터와 계산된 결과를 저장하는데 사용된다. 이를 위한 메모리가 충분하지 않은 경우 시스템은 주요 정보를 삭제하거나 축소해야 하며 이를 다시 계산하거나 또는 추가 처리로 대체하는 경우 CPU 오버헤드가 증가한다. 따라서 메모리 병목상태가 실제로 디스크 또는 CPU 문제처럼 나타날 수 있다.다음 표에서는 메모리가 잠재적인 기본 원인인 디스크 및 CPU 병목상태를 요약한다.대부분의 메모리 병목상태는 CPU나 디스크의 병목상태 증상으로 나타나며 이러한 문제를 조사해보면 주로 메모리 문제가 가능성이 된다. 하지만 사용 가능한 메모리 부족(vmstat 명령의 실행으로 표시됨)이 처음부터 성능 저하와 함께 주요 증상이 되는 일이 발생할 수도 있다. vmstat 데이터를 좀더 조사하여 시스템 CPU 사용량의 증가가 있건 없건 간에 지속적인 페이징 활동이 나타나는 경우 시스템에 과도한 메모리 압력이 있는 것이다.DB2 시스템의 메모리 할당은 다음 두 개의 광범위한 범주 내에 속한다.

1. 데이터베이스와 인스턴스 레벨 할당 (예: 공유 데이터베이스 메모리) : 이것으로부터 버퍼 풀, 정렬 힙, 잠금 목록, 패키지 캐시 같은 것들이 할당된다. 메모리 소스의 과도한 할당이 확인되면 결합된 할당이 데이터베이스 연결 수에 독립적이기 때문에 공유된 메모리가 이를 처리하기 쉬워진다. 이러한 할당은 DATABASE_MEMORY 구성 매개변수로 제한된다.
2. 연결 레벨 또는 애플리케이션 할당 (예: 애플리케이션 힙 또는 문 힙) : 연결 레벨 할당에 의해 소비되는 총 메모리 양은 연결 수에 따라 다르기 때문에 초기 시스템 구성시 어느 정도 예측하기 어려울 수 있다. DB2 버전 9.5에서는 애플리케이션당 메모리가 INSTANCE_MEMORY 하에 있기 때문에 연결의 갑작스러운 스파이크로 인해 ‘치솟는' 할당의 가능성이 적어진다.

명시적인 힙 크기를 지정했건 또는 STMM을 대신 사용했건 간에 실제 DB2 메모리 소비를 확인하는 가장 좋은 방법은 구성된 현재 힙 크기를 데이터베이스, 인스턴스, 애플리케이션 레벨에 각각 제공하는 데이터베이스, 데이터베이스 매니저, 애플리케이션 스냅샷(또는 SYSIBMADM.SNAPDB_MEMORY_POOL, SNAPDBM_MEMORY_POOL, SNAPAGENT_MEMORY_POOL 관리 뷰)의 메모리 사용량 섹션을 사용하는 것이다. 이렇게 하면 구성된 현재 힙과 애플리케이션 할당을 검사하고 현재 총 할당을 확인할 수 있다.DB2 버전 9.5 메모리 사용의 최상위 한도는 INSTANCE_MEMORY 데이터베이스 매니저 구성 매개변수와 DATABASE_MEMORY 데이터베이스 구성 매개변수로 적용된다. 대부분의 플랫폼에서 이러한 매개변수의 기본값은 AUTOMATIC으로 인스턴스별 또는 데이터베이스별 메모리 사용량이 변동될 수 있으며, 지원되는 경우 DB2 데이터베이스와 시스템 상황의 필요에 따라 DB2 데이터베이스 제품이 OS로부터 메모리를 가져와서 OS로 메모리를 반환함을 의미한다. 이러한 매개변수의 현재 숫자 값은 GET DATABASE MANAGER CONFIGURATION, GET DATABASE CONFIGURATION 명령에 SHOW DETAIL 옵션을 사용하여 가져올 수 있다. 그러므로 DB2 메모리 관리 시스템은 여기서 고려되는 종류의 메모리 병목상태를 방지하도록 디자인되었다.메모리 병목상태는 다음과 같은 상황에서 발생할 수 있다.

1. INSTANCE_MEMORY가 명시적으로 AUTOMATIC이 아닌 숫자 값으로 설정되어 있고 STMM이 활성화된 경우 STMM은 바로 DB2 메모리 소비를 INSTANCE_MEMORY의 값으로 조정한다.
   이 경우 INSTANCE_MEMORY가 AUTOMATIC으로 설정되지 않았기 때문에 STMM은 메모리를 해제함으로써 시스템의 메모리 압력에 반응하지 않는다. 따라서 DB2 시스템과 다른 주요 메모리 소비자(예: 애플리케이션 서버)의 결합은 총 시스템 전반 메모리 사용량을 지나치게 높일 수 있다. UNIX 시스템의 ps 명령 또는 Windows의 작업 관리자(task manager)는 프로세스별 메모 있는 메모리 소비자를 추적하는 데 대단히 유용한 도구이다.
   이전에 언급한 것처럼 기술적으로는 파일 시스템 캐시 메모리를 DB2 데이터베이스와 같은 소비자가 사용할 수 있다고 해도 대용량의 파일 시스템 캐시(특히 메모리를 다른 메모리 사용자에게 해제하기 전에 디스크로 플러시되어야 하는 수정된 데이터의 캐시)는 메모리에 대한 추가 요구가 발생하는 경우 페이징을 일으키는 경우가 될 수 있다.
2. 서버에서 DB2 데이터베이스가 아닌 다른 것으로부터의 막대한 메모리 소비가 불가피한 경우 INSTANCE_MEMORY 매개변수를 AUTOMATIC으로 설정하거나 DB2 데이터베이스가 사용할 수 있는 시스템 메모리의 실제 부분을 반영하도록 축소해야 한다.
   시스템에 비해 INSTANCE_MEMORY의 명시적인 값이 너무 크면 추가 데이터베이스가 온라인이 되어 총 DB2 데이터베이스 할당을 시스템에서 수용할 수 있는 것보다 높이지만 여전히 INSTANCE_MEMORY 내에 있을 때까지는 문제가 되지 않을 수 있다.
   STMM은 필요한 경우 메모리를 다시 OS로 해제함으로써 메모리 압력을 극복하도록 디자인되었기 때문에 이러한 시나리오는 대부분 STMM이 활성화되어 있지 않거나 관련된 플랫폼(예: Solaris 운영 체제)에서 OS로의 메모리 해제를 지원하지 않거나 데이터베이스의 메모리 요구가 지나치게 동적인 경우(예: 데이터베이스 연결의 빠른 생성과 소멸 또는 매우 짧은 기간 동안의 데이터베이스 활성화) 발생할 가능성이 높다.
3. 매우 많은 수의 데이터베이스를 연결해야 하는 경우 이로 인해 에이전트가 많은 부분의 인스턴스 메모리를 소비할 수 있다.
   이 양이 과도한 경우 STMM을 사용하건 사용하지 않건 데이터베이스 전역 메모리 할당을 위한 메모리가 너무 적어지므로 연결 집중 장치의 사용을 통해 줄여야 한다.

‘지연 시스템' 병목상태

시스템 병목상태 > 지연 시스템

병목상태 조사 대상 중 네 번째로 가장 흥미로운 범주는 ‘지연 시스템' 병목상태다. 이 상태는 이전 병목상태 영역 중 어느 것도 문제로 드러나지 않는 경우에 해당된다. CPU, 디스크, 메모리, 네트워크와 관련된 요소에 의한 명백한 병목상태는 없지만 시스템이 더 이상 진전될 수 없다.‘지연 시스템'의 가장 일반적인 문제는 잠금 경합(lock contention)이다. 다행히 잠금 경합은 스냅샷 데이터에서 감지하기 쉽다. SYSIBMADM.SNAPDB를 통해 사용할 수 있는 LOCK_WAIT_TIME, LOCKS_WAITING 스냅샷 요소는 각각 총 잠금 대기 시간과 현재 잠금을 기다리는 에이전트 수를 나타낸다. 잠금을 기다리는 활성 에이전트의 비율이 높거나(예: 20% 이상) 잠금 대기 시간 값의 증가는 잠금이 심각한 병목상태일 수 있음을 나타낸다.

시스템 병목상태 > 지연 시스템 > 잠금 대기

사용 가능한 문당 잠금 대기 시간 진단은 없지만 CPU 소비와 관련된 확장된 실행 시간과 동적 SQL 스냅샷, 문 이벤트 모니터의 I/O 활동은 일반적으로 문이 잠금 대기 시간에 의해 영향을 받는 다는 것을 잘 나타낸다. 또한 애플리케이션 스냅샷도 애플리케이션에 의한 잠금 대기 시간을 표시하여 시스템 측 잠금 대기 문제가 시작된 지점의 범위를 좁히는데 매우 유용할 수 있다. 잠금 대기에 대한 자세한 내용은 SYSIBMADM.SNAPLOCKWAIT 뷰에서 얻을 수 있다.여기에는 다음과 같은 정보가 표시된다.

• 잠금 유형 공유 또는 단독
• 개체 유형 행, 테이블 등
• 보유자 및 요청자의 에이전트 ID

많은 다른 유형의 DB2 스냅샷 모니터 데이터와는 달리 잠금 정보는 매우 일시적이다. 실행 중인 전체인 LOCK_WAIT_TIME 이외에 대부분의 다른 잠금 정보는 잠금 자체가 해제되면 사라진다. 따라서 잠금 및 잠금 대기 스냅샷은 전개되는 그림을 보다 잘 이해할 수 있도록 일정한 기간 동안 주기적으로 수집하는 경우 가장 가치가 있다. 앞에서 제안한 것처럼 대용량의 모니터 데이터 분석에 가장 좋은 방법은 관리 뷰를 통해 데이터를 수집하여 DB2에 저장하는 것이다. 특히 애플리케이션, 데이터베이스 및 잠금 스냅샷으로부터의 데이터로 구성되어 GET SNAPSHOT 명령으로부터 이러한 양식으로 사용할 수 없는 SNAPLOCKWAIT에서 가져온 데이터인 경우가 여기에 해당된다.또한 다른 유형의 스냅샷과 달리 잠금 스냅샷의 주 오버헤드는 스냅샷을 만들 때 발생하며 잠금 모니터 스위치를 통해 스냅샷을 활성화시키는 경우는 오버헤드가 없다. 따라서 규칙적으로 잠금 스냅샷을 수집하고 분석을 위해 저장하는 것이 유용하다고 하더라도 스냅샷을 지나치게 자주 만들면 그 자체로 병목상태를 일으킬 수 있다.다음은 잠금 경합 및 잠금 대기 시간을 줄이는 데 도움을 주는 몇 가지 지침이다.

1. 가능하면 너무 긴 트랜잭션과 WITH HOLD 커서를 사용하지 않는다. 잠금을 길게 유지하면 다른 애플리케이션과 경합을 일으킬 가능성이 커진다.
2. 반입 결과 세트가 특히 반복 가능한 읽기(RR) 격리 수준에서 필요 이상으로 크지 않도록 한다. 행을 많이 사용할수록 잠금이 더 많아지며 이에 따라 다른 사람의 잠금과 충돌할 가능성이 높아진다. 실제로 이것은 더 많은 행을 반환하여 애플리케이션에서 필터링하는 것이 아니라 주로 행 선택 조건을 SELECT 문의 WHERE 절로 끌어 내리는 것을 의미한다. 예를 들어 다음과 같다.
3. 필요 이상으로 높은 격리 수준을 사용하지 않아야 한다. 반복 가능한 읽기는 애플리케이션에서 결과 세트 통합을 유지하는데 필수적일 수도 있다. 하지만 보유한 잠금과 잠재적인 잠금 충돌 측면에서 추가 비용이 발생한다.
4. 애플리케이션의 비즈니스 로직에 적합한 경우 DB2_EVALUNCOMMITTED, DB2_SKIPDELETED, DB2_SKIPINSERTED를 통한 잠금 동작의 수정을 고려한다. 이 레지스트리 변수는 DB2가 일부 환경에서 잠금을 지연하거나 회피하여 경합을 줄이고 잠재적으로 처리량을 향상할 수 있게 한다.

잠금 에스컬레이션은 경합의 주요 원인이 될 수도 있다. 잘 디자인된 애플리케이션에서 수행한 개별 행 잠금은 충돌하지 않을 수 있지만 에스컬레이션으로 인한 블록 레벨 또는 테이블 레벨 잠금은 일련화(serialization)나 극심한 성능 문제를 일으킬 가능성이 매우 높다. 데이터베이스 스냅샷은 잠금 에스컬레이션의 전역 카운트를 표시한다(SYSIBMADM.SNAPDB.LOCK_ESCALS). 이는 대부분 각 에스컬레이션이 발생하면 (DIAGLEVEL 3에서) db2diag.log에 쓰여진 메시지를 조사하여 개별 테이블의 에스컬레이션으로 쉽게 분리될 수 있다.잠금 에스컬레이션은 애플리케이션이 잠금 목록의 허용된 부분을 사용할 때 발생한다(잠금 목록의 허용된 부분은 잠금 목록 크기의 비율로 표현되는 데이터베이스 구성 매개변수인 MAXLOCKS에 의해 결정된다). 따라서 MAXLOCKS 또는 LOCKLIST를 증가시키면 에스컬레이션의 가능성 또는 빈도를 줄일 수 있다. 뿐만 아니라 위에서 언급한 것처럼 애플리케이션에서 수행한 잠금의 수를 커밋 빈도를 늘리거나 격리 수준을 줄이는 등의 방법을 통해서 줄이면 에스컬레이션을 줄일 수 있다.

시스템 병목상태 > 지연 시스템 > 교착상태 / 잠금 시간초과

잠금 대기 시간은 상당히 미세한 병목상태일 수 있지만 교착상태와 잠금 시간초과는 모두 애플리케이션에 네거티브 SQL 코드를 반환하기 때문에 무시하기 어렵다. 그렇다고 해도 대부분의 애플리케이션은 실패한 트랜잭션을 다시 시도하여 결국에는 성공하여 교착상태를 보고하지 않는다. 이런 경우 잠재적인 교착상태 문제에 대한 가장 확실한 표시는 SYSIBMADM.SNAPDB 관리 뷰의 DEADLOCK 요소다. 위에서 언급한 것처럼 이러한 정보는 정기적인 운영 모니터링의 일부로 수집하는 것이 좋다.교착상태의 비용은 다양하며 롤백된 트랜잭션의 길이에 직접적으로 비례한다. 그래도 트랜잭션 1000개당 교착상태가 둘 이상이면 일반적으로 문제가 있음을 나타낸다.교착상태 빈도는 때때로 전체 애플리케이션이 공용 데이터를 동일한 순서, 즉 예를 들어 애플리케이션이 테이블 A의 행을 액세스하고(이에 따라 잠김) 이어서 테이블 B, 테이블 C 등의 순서로 액세스하게 하면 간단히 감소될 수 있다. 두 애플리케이션이 다른 순서로 동일한 개체에 호환되지 않는 잠금을 수행하면 훨씬 큰 교착상태의 위험을 감수하게 된다.기본 교착상태 이벤트 모니터 DB2DETAILDEADLOCK은 dftdbpath(데이터베이스 매니저 기본 데이터베이스 경로) 하에 있는 모든 교착상태 참가자에 대한 정보를 기록한다. 예를 들어 <dftdbpath>/NODE0000/SQL00001/db2event/db2detaildeadlock에 있는 모든 정보를 기록하면 된다.모든 이벤트 모니터와 마찬가지로 이 이벤트 모니터도 적은 양의 추가 오버헤드를 부과한다. 하지만 일반적으로 교착상태를 추적할 수 있다는 이점은 적은 성능 불이익보다 중요하다.과도한 수의 잠금 시간초과는 교착상태만큼 시스템에 치명적일 수 있다. 일반 교착상태 이벤트 모니터는 잠금 시간초과를 추적하지 않기 때문에 다른 메커니즘이 필요하다. DB2 버전 9.5는 잠금 시간초과에 대해 텍스트 기반 보고서를 생성하는 기술을 지원한다. 이 기술은 교착상태 이벤트 모니터에 기타 엔진 내 인프라를 토대로 한다. 또한 이전 릴리스에 대한 잠금 시간초과 진단을 상당히 단순화했다.잠금 시간초과 보고서를 생성하는 과정은 developerWorks의 “DB2 9.5의 잠금 시간초과 분석을 위한 새로운 옵션(New options for analyzing lock timeouts in DB2 9.5, http://www.ibm.com/developerworks/db2/library/techarticle/dm-0804fechner )”에 설명되어 있다.

필자소개

Steve Rees:DB2 성능 품질관리 선임 매니저
Thomas Rech:DB2 SAP Center of Excellence 선임 컨설턴트
Gang Shen:IBM Data Servers 기술 영업 전문가
Roman B. Melnyk:DB2 Information Development출처 : KDUG (http://www.kdug.kr/)제공 : DB포탈사이트 DBguide.net