기술자료
DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.
DB2 튜닝 가이드 Part 4: 시스템 성능 모니터링 대부분의 DB2 시스템은 '성능 전개(performance evolution)' 과정을 거친다. 시스템을 배포한 후 시스템 모니터링을 하고, 만약 문제점이 발생되면 문제해결 과정을 거친다. DB2 튜닝 가이드는 단계별로 최상의 성능을 위한 최적의 설정을 제시함으로써, DB2 시스템 성능이 최상을 유지하도록 도와준다. 이번 회에서는 초기 시스템 구성 후 여러 시스템 성능 메트릭(metric)을 추적할 수 있는 모니터링 기술에 대해 알아본다.<연재순서>
DB2 튜닝 가이드 Part 1: 최상의 성능을 위한 시스템 구성 DB2 스냅샷 메트릭의 ‘스타터 셋(starter set)' 필자소개DB2 튜닝 가이드 Part 4: 시스템 성능 모니터링
DB2 튜닝 가이드 Part 2: 최상의 성능을 위한 DB 구성 (1)
DB2 튜닝 가이드 Part 3: 최상의 성능을 위한 DB 구성 (2)
DB2 튜닝 가이드 Part 4: 시스템 성능 모니터링
- 이해하기 쉬운 메트릭: 메트릭을 볼 때마다 해당 의미를 찾아볼 필요가 없어야 한다.
- 시스템과 관련된 메트릭: 모든 메트릭이 전체 환경에서 중요한 정보를 제공하는 것은 아니다.
- 민감하지만 지나치게 민감하지 않은 메트릭: 메트릭의 변경사항은 시스템의 실제 변경사항을 나타내야 한다. 메트릭 자체가 불안정해서는 안 된다.DB2 데이터베이스 제품에는 모니터링 요소가 많이 있다. 다음은 이러한 요구사항을 충족시키는 요소들에 대해서 살펴본다.우선 작업 모니터링과 예외 모니터링 간의 차이점을 살펴본다. 작업 모니터링은 일일 기준 모니터링이며, 예외 모니터링은 문제를 진단할 수 있는 추가 데이터 수집이다.작업 모니터링과 예외 모니터링과의 기본적인 차이는 작업 모니터링의 경우 매우 경량(측정하는 데 시스템을 많이 소비하지 않음)이고 일반적(시스템 어디에나 나타날 수 있는 잠재적인 문제점을 광범위하게 감시)이어야 한다. 본 글에서는 기본적으로 작업 모니터링에 중점을 둔다.DB2 데이터베이스 시스템은 모니터링 데이터 소스를 제공한다. 가장 중요한 스냅샷 모니터가 있다. 특히 DB2 9.5이상에는 워크로드 관리(WLM) 집계 기능이 있다. 이 두 기능은 카운터, 타이머, 히스토그램과 같은 도구가 시스템에서 실행중인 활동을 관리하는 요약 데이터에 초점을 둔다. 이러한 모니터 요소를 시간이 흐름에 따라 샘플링하여 시작과 종료 시간 사이에 발생한 평균 활동을 이끌어 낼 수 있으며, 이는 대단히 유용한 정보가 된다.사진 같은 유추(analogy), 스냅샷, 집계 통계를 사용하며 시스템 활동에 대한 단일 그림을 제공한다. 일부 경우 이런 그림은 플래시 사진과 같이 순간적이지만 대부분의 경우 일정한 기간 동안 발생한 활동을 보여주는 ‘시간 노출(time exposure)'이다.DB2는 일련의 개별 활동에 대한 실행 스트림을 기록하는 ‘영화(motion picture)' 모니터링을 제공한다. 이 기능은 명령문 이벤트 모니터와 같은 이벤트 모니터와 밀접하게 관련된 WLM 활동 모니터와 같이 추적과 같은 매커니즘을 사용하여 수행한다. 이러한 방법은 스냅샷에서 얻은 요약보다 시스템 활동에 대해 보다 자세하고 이해하기 쉬운 기록을 제공한다. 그러나 추적은 엄청난 양의 데이터를 만들어 내기 때문에 시스템에 과중한 오버헤드를 부과한다. 따라서 작업 모니터링 보다는 예외 모니터링에 더 적합하다.DB2에서 제공하는 메트릭에만 제한할 필요는 없다. 실제로 DB2가 아닌 데이터가 중요할 수 있다. 컨텍스트(contextual) 정보는 성능 문제 확인을 위해 중요하다. 사용자, 애플리케이션, 운영체제, 스토리지 서브시스템과 네트워크 등 모두가 시스템 성능에 대한 가치 있는 정보를 제공한다. 시스템 성능에 대한 전체 그림을 그리기 위해서는 DB2 데이터베이스 외의 다른 인프라를 통해 가져온 메트릭을 포함해야 한다.시스템을 사용하는 동안 작업 메트릭을 정기적으로 수집하기 위해서는 이러한 데이터를 모두 관리할 수 있는 방법이 있어야 한다. 데이터를 다양하게 사용하기 위해서는 수 개월간 떨어져 있었던 데이터의 임의 수집 간의 비교를 수행해야 한다.DB2 제품 자체에 이러한 유형의 데이터 관리를 활용할 수 있다. 모니터링 데이터의 분석과 비교가 매우 간단해졌으며, 장기적인 데이터 스토리지와 구성을 위한 강력한 인프라가 있다.
최근 출시한 DB2 제품들은 SQL 인터페이스를 통해 더욱더 많은 모니터링 데이터를 사용할 수 있다. 데이터 관리 뷰로부터 데이터를 쉽게 리디렉션 할 수 있기 때문에 DB2와 함께 모니터링 데이터의 관리가 매우 간단해졌다.좀 더 자세히 살펴보면, 이벤트와 활동 모니터 데이터를 DB2 테이블에 쓸 수 있어 유사한 혜택을 얻을 수 있다. 모니터링 데이터는 DB2에 쉽게 저장할 수 있기 때문에 시스템 메트릭(예, vmstat으로부터의 CPU 활용)도 쉽게 DB2에 저장할 수 있다.
시스템 활동에 대한 기본 레벨 측정값을 제공한다.
2. 데이터, 인덱스와 임시 데이터에 대해 개별적으로 측정된 버퍼 풀 적중률(hit ratio)
버퍼 풀 적중률은 가장 기본적인 메트릭으로 시스템이 디스크 I/O를 방지하기 위해 메모리를 얼마나 효율적으로 활용하는지에 대한 주요 측정값을 제공한다. 데이터 적중률이 80~85% 이상, 인덱스에 적중률 90~95% 이상이면, 일반적으로 OLTP 환경에서는 양호한 편으로 간주한다. 물론 이러한 비율은 버퍼 풀 스냅샷에서 가져온 데이터를 사용하여 개별 버퍼 풀에 대해 계산될 수 있다.대형 테이블 스캔을 자주 수행하는 데이터 웨어하우스 시스템의 경우 데이터 적중률이 낮은 경우가 많다. 데이터 웨어하우스 시스템의 경우 메트릭이 유용하지만 데이터가 버퍼 풀에서 읽혀진 다음 다른 데이터를 위해 제거되기 전까지 다시 사용되지 않기 때문이다.3. 트랜잭션당 버퍼 풀 읽기와 쓰기
이 메트릭은 버퍼 풀 적중률과 밀접하게 관련되어 있지만 용도는 약간 다르다. 적중률에 대한 대상 값은 이야기할 수 있지만 트랜잭션당 읽기와 쓰기에 대해 가능한 대상은 없다.이러한 계산은 굉장히 중요하다. 디스크 I/O는 데이터베이스 성능에 있어 중요한 요소이기 때문에 여러 측면에서 살펴보는 것이 유용하다. 또한 이 계산에는 쓰기가 포함되어 있다. 그러나 적중률은 읽기만 다룬다.마지막으로 이들을 분리할 경우 예를 들어 94%의 인덱스 적중률이 개선할만한 가치가 있는지 여부를 알기 어렵다. 만약 시간당 논리적 인덱스 읽기를 100개만 수행하고 이들 중 94개가 버퍼 풀에 있는 경우 마지막 6개를 실제 읽기로 전환하지 못하도록 막는데 시간을 사용하는 것은 바람직하지 않다. 그러나 각 트랜잭션이 실제 읽기 20개를 수행했다는 통계와 함께 94%의 인덱스 적중률이 표시된 경우 버퍼 풀 적중률을 조사해 봐야 한다. 실제 읽기는 이후에 데이터와 인덱스, 정규와 임시로 나뉠 수 있다.이러한 메트릭은 단지 ‘실제 읽기와 쓰기' 만이 아니라 트랜잭션당 표준화가 된다. 여러 메트릭을 통해 이러한 추세를 따른다. 데이터를 수집한 시간 길이와 해당 시간에 시스템 사용률의 빈도 여부로 메트릭을 분리하는 데 목적이 있다. 일반적으로 이렇게 함으로써 모니터링 데이터를 언제 어떻게 수집했는지 정확하지 않아도 메트릭에 대해 유사한 값을 얻게 된다.데이터 수집의 타이밍과 기간에 일관성이 있어야 한다. 이러한 일관성은 ‘중요한(critical)' 것이 아닌 ‘바람직한 생각(a good idea)'으로 축소된다.4. 선택한 행에 대한 데이터베이스 행 읽기 비율
이 계산은 자격이 있는 행을 찾기 위해 데이터베이스 테이블에서 읽혀진 행의 평균 개수를 나타낸다. 숫자가 낮으면 데이터 찾기가 효율적임을 나타내며 일반적으로 인덱스가 효과적으로 사용되고 있음을 나타낸다. 예를 들어 시스템이 대량의 테이블 스캔을 수행하고 결과 세트에 대해 자격이 있는지 여부를 결정하기 위해 수백만 행을 검사해야 하는 경우 이 숫자가 매우 높을 수 있다. 다른 한편 정규화된 고유 인덱스를 통해 테이블을 액세스하는 경우엔 통계치가 매우 낮을 수 있다. 액세스 계획(index-only access plan)은 테이블에서 행을 읽을 필요가 없기 때문에 ROWS_READ가 증가되지 않는다.OLPT 환경에서 이 메트릭은 일반적으로 2 또는 3보다 낮으며 이는 대부분의 액세스가 테이블 스캔이 아닌 인덱스를 통해 수행된다. 이 메트릭은 시간이 지남에 따라 계획의 안정성을 모니터링하는 간단한 방법이다. 예기치 않은 값의 증가는 주로 인덱스가 더 이상 사용되지 않음을 조사해야 한다.5. 트랜잭션당 정렬에 소비된 시간의 양
이 메트릭은 정렬 통계를 처리하는 효율적인 방법이다. 유출된 정렬로 인한 추가 오버헤드가 자동으로 포함되어 있기 때문이다. 특별히 시스템 정렬 문제에 대한 기록이 있는 경우 분석이 용이하도록 TOTAL_SORTS와 SORT_OVERFLOWS를 수집할 수 있다.6. 트랜잭션 1000개당 누적된 잠금 대기 시간의 양
과도한 잠금 대기 시간은 응답 시간의 저하를 의미하기 때문에 모니터링하는 것이 중요하다.
단일 트랜잭션의 잠금 대기 시간은 일반적으로 낮기 때문에 트랜잭션 1000개로 표준화 됐다. 트랜잭션 1000개로 확대하면 보다 처리하기 쉬운 측정값이 제공된다.7. 트랜잭션 1000개당 교착 상태(deadlock)와 잠금 시간 초과 수
대부분의 프로덕션 시스템에서 교착 상태는 비교적 드물지만 잠금 시간초과는 흔히 발생한다. 애플리케이션은 일반적으로 유사한 방법으로, 즉 처음부터 트랜잭션을 다시 실행하여 처리한다. 어떤 비율에서 이러한 상황이 발생하는지 모니터링 함으로써 교착 상태와 잠금 시간 초과로 인해 DBA가 인식하지 못하는 사이에 시스템에 심각한 추가 로드가 발생하는 것을 막을 수 있다.8. 트랜잭션 1000개당 dirty steal 트리거(trigger) 수
‘dirty steal'은 버퍼 풀을 정리할 때 가장 선호되지 않는 방법이다. 기본적으로 새로운 버퍼 풀 페이지를 필요로 하는 SQL 명령문이 있는 경우 제거될(victim) 페이지의 업데이트를 디스크에 쓰는 동안 처리가 중단된다. dirty steal이 자주 발생되면 처리량과 응답 시간에 심각한 영향을 미칠 수 있다.9. 트랜잭션 천 개당 패키지 캐시 삽입 수
패키지 캐시 삽입은 시스템의 정상 실행에 속한다. 그러나 그 수가 많으면 CPU 시간을 소비하고 있다는 의미이다. 대부분 잘 디자인된 시스템에서는 시스템이 안정된 상태로 실행되고 난 후, 패키지 캐시 삽입이 거의 일어나지 않는다. 왜냐하면 시스템은 정적 또는 미리 준비된 동적 SQL 명령문을 사용하거나 재 사용하기 때문이다. 임의(ad hoc) 동적 SQL 명령문의 트래픽이 매우 높은 시스템의 경우, SQL 컴파일과 패키지 캐시 삽입은 불가피하다. 그러나 이 메트릭은 애플리케이션이 준비된 명령문을 다시 사용하지 않거나 자주 실행되는 SQL에서 매개변수 마커를 사용하지 않음으로써 실수로 패키지 캐시를 발생시키는 세 번째 유형의 상황을 감시한다.10. 트랜잭션당 로그 활동의 양
트랜잭션 로그는 높은 레벨의 활동, 잘못된 구성 또는 기타 원인으로 인해 시스템 병목 상태를 만들 가능성이 높다. 쓰기 개수와 시간을 포함하여 로그 활동을 모니터링하면 DB2에서 발생하는 문제(애플리케이션에 의한 로그 요청 수의 증가)와 시스템에서 발생하는 문제(하드웨어 또는 구성 문제에 의해 발생하는 로그 서브시스템 성능의 저하로 인한 경우) 모두를 감지한다.11. 분할된 데이터베이스 환경에서 파티션 간에 송수신된 FCM(fast communication manager) 버퍼 수
이 개수는 클러스터 내 다른 파티션 사이의 데이터 흐름 비율, 특히 흐름의 균형이 맞는지 여부를 나타낸다. 다른 파티션에서 수신된 버퍼 수의 큰 차이는 각 파티션에 해시된 데이터 양의 불일치를 나타낸다.SYSIBMADM.SNAPFCM_PART를 쿼리하면 GET SNAPSHOT FOR FCM에서 제공하는 정보인 현재 데이터베이스 파티션과 관련된 송신, 수신만이 아닌 시스템에 있는 전체 파티션 쌍(pair) 사이의 흐름에 대한 정보를 제공한다. 현재 데이터베이스 파티션과 관련된 데이터만 반환하려면 다음과 같이 DBPARTITIONNUM에 술어를 추가한다.
DB2 모니터링 요소가 주요 작업 데이터를 제공하기는 하지만 위에서 언급한 것처럼 다음과 같은 다른 유형의 데이터로 데이터를 증가시키는 것이 중요하다.
위에 설명한 메트릭은 지속적으로 수집할만한 중요한 데이터 세트를 대표한다. 스냅샷 모니터링 요소와 시스템 로드 데이터는 크기가 작아서 매 5~15분마다 수집한다고 해도 시간이 지남에 따른 총 데이터 볼륨이 시스템에서 문제가 되지 않는다.마찬가지로 이 데이터 수집에 따른 오버헤드도 일반적으로 1~3% 범위 내의 추가 CPU를 소비하며 이는 중요한 시스템 메트릭의 지속적인 기록 측면에서 보면 아주 작은 노력이다. 구성 정보는 상대적으로 거의 변경되지 않기 때문에 하루에 한 번 수집하면 일반적으로 과도한 양의 데이터를 만들지 않으면서 유용하게 사용할 수 있다.
현재 환경과 시스템의 상황에 따라 이러한 코어 메트릭 이외에 다음과 같은 추가 데이터를 수집하는 것이 유용하다.
추가 모니터링 데이터를 드릴다운하고 수집하려는 경우 어떤 필드가 필요할지 미리 예측하는 대신 관리 뷰에서 제공하는 모든 요소 중 관심 있는 요소를 수집하는 것이 가장 간단한 방법이다.
위에서 언급한 모든 개별 모니터링 요소 값은 거의 파티션 별로 보고된다. 단일 OS 인스턴스가 여러 논리적 DB2 파티션에 걸쳐 있을 수 있음에도 불구하고, 이에 대한 통계를 보고하는 vmstat와 iostat 같이 DB2가 아닌 수집 가능한 성능 데이터의 경우도 마찬가지다.모니터 세분성은 시스템을 제어하기 위해 사용하는 DB2 구성 매개변수의 세분성과 일치하는 경우 유용하다. 하지만 분할된 데이터베이스 환경에서 파티션 사이에 상대적인 활동도 모니터링할 수 있다. 파티션당 데이터 볼륨의 불균형 감지를 위한 활동이 이러한 예이다.관리 뷰로부터 수집하는 DB2 모니터링 데이터에는 DBPARTITIONNUM 열 값이 포함되어 있다. 그래서 필요한 경우 파티션 번호로 모니터링 데이터를 쿼리할 수 있을 뿐 아니라 전체 파티션에서도 비교할 수 있다.일반적으로 모니터링 통계는 대부분 같은 DB2 파티션 그룹에 있는 전체 파티션에서 거의 같다. 통계의 큰 차이는 데이터 불일치를 나타낸다. 이를 추적하기 위한 샘플 상호 파티션 비교에는 다음이 포함된다.
이러한 메트릭을 살펴보고, 특정 데이터 파티션이 같은 파티션 그룹에서 활발하지 않은 데이터 파티션보다 현저하게 활발한 것으로 나타나면(사용률이 10~20% 이상인 경우), 사용률이 높은 파티션이 CPU 또는 I/O를 모두 소모하는 경우 데이터 파티션을 다시 분할해야 한다. 각 파티션에 해시된 각각의 분할된 대형 테이블에서 행 수를 찾으면 심각한 불일치가 있는지 여부를 확인할 수 있다.
<물리적 데이터베이스 디자인> http://www.ibm.com/developerworks/data/bestpractices/ 에서는 시스템의 올바른 파티션 키를 선택하기 위해 DB2 Design Advisor를 사용하여 데이터 불일치를 방지하고 연결되지 않은 조인(non-collocated join)을 최소화하는 방법에 대해 설명한다.
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