DB2 튜닝 가이드 Part 1: 최상의 성능을 위한 시스템 구성

대부분의 DB2 시스템은 ' 성능 전개 (performance evolution) ' 과정을 거친다 . 시스템을 배포한 후 시스템 모니터링을 하고 , 만약 문제점이 발생되면 문제해결 과정을 거친다 . DB2 튜닝 가이드는 단계별로 최상의 성능을 위한 최적의 설정을 제시함으로써 , DB2 시스템 성능이 최상을 유지하도록 도와준다 . 최적의 성능을 위해 기본이 되는 하드웨어와 소프트웨어의 중요 개념과 다양한 모니터링 기술 그리고 예상치 못한 성능 저하 문제를 해결하는 방법 등을 소개한다 . 이번 회는 DB2 튜닝 가이드의 첫 회로 , 최상의 성능을 위해 필요한 구 성 중 하드웨어 , OS 등 시스템 구성 설정을 중심으로 알아본다 .

어떤 형태로든 시스템 성능에 문제가 발생하면 기업의 업무 처리에도 적지 않은 영향이 생긴다 . 작업 능력의 저하 , 서비스 중단 , 관리 오버헤드의 증가 등은 TCO(Total Cost Ownership) 를 높이는 주 요인이다 . 그러나 시스템의 구성 설정 , 모니터링 그리고 성능 문제 해결의 기본 원리에 대한 이해가 부족하면 심각한 문제는 물론 , 간단한 문제조차도 해결하지 못하는 경우가 생긴다 . 초기에 기본 설정 가이드라인을 고려하고 견고한 시스템 모니터링 관 례 (practices) 를 구축하는데 시간을 투자함으로써 , 다양하게 발생할 수 있는 성능 문제에 대처할 수 있어야 한다 . 성능 문제에 올바르게 대처하면 데이터 서버를 보다 효과적으로 운영할 수 있으며 이는 향상된 ROI(Return on Investment) 로 연결된다 .

First Step:최상의성능을위한구성

일부 DB2 배포 유형의 경우 해당 구성이 상세하게 지정되어 있다 . InfoSphere Balanced Warehouse(BW) 와 SAP 시스템 내부의 형태 등이 그 예이다 . BW 의 경우 , CPU 개수와 CPU 에 대한 메모리 비율 , 디스크 수와 구성 , 버전 등과 같은 하드웨어 요소는 최적의 구성을 결정하기 위한 철저한 테스팅을 기반으로 미리 지정된다 . SAP 경우는 하드웨어 구성이 상세하게 지정되어 있진 않지만 사용할 수 있는 샘플 구성이 많다 . 더욱이 SAP 베스트 사례는 권장된 DB2 구성 설정을 제공한다 . 만약 충분히 테스트된 구성 지침을 제공하는 시스템을 위해 DB2 배포를 사용한다면 일반적인 경험보다는 해당 지침을 활용해야 한다 .이번 글에서는 시스템이 최상의 성능을 내도록 하기 위한 몇 가지 주요 구성 설정을 확인한다 . 이 과정은 일반적으로 시스템을 실행하기 전에 수행되기 때문에 , 실제로 시스템이 어떻게 작동할 것인지를 아는 것은 한계가 있다 . 따라서 시스템이 어떻게 작동될 것인지에 대한 기본 지식을 기반으로 ‘ 최선의 추측 (best guess)' 을 해야 한다 . 시스템에서 수집한 실제 모니터링 데이터를 기반으로 하는 상세한 설정 사항과 문제 해결에 대해서는 본 글의 후반부에서 다룬다 .

하드웨어구성

CPU 용량은 시스템을 구성할 때 성능을 위한 주요 독립 변수 중 하나이다 . 일반적으로 모든 다른 하드웨어 구성이 CPU 로부터 나오기 때문에 주어진 워크로드에 필요한 CPU 용량을 예측하기란 어렵다 . 비즈니스 인텔리전스 (Business Intelligence) 환경에서의 예상치는 프로세스 코어당 200~300GB 의 활성 원시 데이터 (active raw data) 가 적절하다 . 다른 환경의 경우 , 필요한 CPU 용량을 측정하는 방법은 하나 이상의 기존 DB2 시스템을 기반으로 하는 것이다 .예를 들어 , 만약 새로운 시스템이 50% 이상의 사용을 처리해야 하고 각 실행 SQL 이 기존 시스템의 SQL 만큼 복잡한 경우 , 50% 이상의 CPU 용량이 더 필요하다고 가정하는 것이 적절하다 . 마찬가지로 다른 처리량 요구사항 , 트리거 사용과 참조 무결성 (integrity) 의 변경 등과 같은 경우 CPU 사용량의 변경이 예상되는 다른 요소도 고려해야 한다 .사용할 수 있는 정보를 이용해 CPU 요구사항에 대해 올바른 개념을 갖게 되면 하드웨어 구성의 다른 측면들이 제대로 구성된다 . 필요한 시스템 디스크 용량을 기가바이트 또는 테라바이트 단위로 고려하지만 성능과 관련하여 가장 중요한 요소는 초당 I/O(IOPS) 또는 데이터 전송의 초당 메가바이트 용량이다 . 이러한 요소는 실제로 연결된 개별 디스크의 수에 의해 결정된다 .왜 그럴까 지난 십 년간 CPU 의 발전은 속도 면에서 놀랍게 향상된 반면 디스크의 경우 용량과 비용 면에서 더욱 많은 발전을 했다 . 디스크 탐색 시간과 전송률은 개선되었지만 CPU 속도를 따라가지 못하고 있다 . 따라서 시스템에 필요한 전체 성능을 달성하려면 디스크를 여러 개 사용하는 것이 무엇보다 중요하다 . 특히 상당한 양의 임의 디스크 I/O 를 필요로 하는 시스템의 경우 더욱 중요하다 . 시스템에 있는 총 데이터의 양을 포함할 수 있는 최소한의 디스크 수에 근접하여 사용하려는 경우가 많은데 , 이같은 결정은 곧바로 성능 저하로 연결된다 .RAID 스토리지 또는 개별적으로 주소 지정이 가능한 드라이브의 경우 , 경험적으로 좋은 방법은 프로세스 코어당 적어도 10 개에서 20 개의 디스크를 구성하는 것이다 . 스토리지 서버의 경우 , 유사한 개수를 권장하지만 이 경우에는 좀더 주의를 기울여야 한다 .스토리지 서버에서의 공간 할당은 처리량 보다는 주로 용량을 목적으로 한다 . 이 경우 논리적으로 분리된 스토리지의 부주의한 중첩이 발생하지 않도록 데이터베이스 스토리지의 물리적인 레이아웃을 이해해야 한다 . 예를 들어 CPU 가 4 개인 시스템의 경우 8 개의 어레이에 각각 8 개의 드라이브가 할당되는 것이 적당하다 . 그러나 8 개 어레이 모두가 8 개의 동일한 물리적 드라이브를 공유한 경우 , 이러한 구성의 처리량은 64 개의 물리적 드라이브에 분포되어 있는 8 개의 어레이에 비해 현저하게 저하된다 .DB2 트랜잭션 로그를 위해서는 공유되지 않은 전용 디스크를 따로 두어야 한다 . 로그의 I/O 특성이 DB2 컨테이너와 다르기 때문이다 . 예를 들어 로그 I/O 와 기타 유형의 I/O 간의 경쟁은 로깅 병목 상태를 초래한다 . 특히 쓰기 (write) 처리가 많은 경우 더욱 그러하다 .일반적으로 디스크를 한 쌍의 RAID-1 으로 구성하는 것은 초당 최대 400 개까지의 쓰기 (write) 집약적인 DB2 트랜잭션에 대해 충분한 로그 처리량을 제공한다 . 처리량 비율 또는 고용량 로깅 ( 예를 들면 , 벌크 삽입 중 ) 이 많을수록 더 많은 로그 처리량이 요구되며 이는 쓰기 - 캐싱 (write-caching) 디스크 컨트롤러를 통해 시스템에 연결되는 RAID-10 구성의 추가적인 디스크가 필요하다 . 로그가 병목 상태인지 알 수 있> 에서 설명한다 .CPU 와 디스크는 서로 다른 시간 단위 ( 나노 초 Vs. 마이크로 초 ) 에서 효과적으로 작동하기 때문에 적절한 처리 성능을 위해 이들을 서로 분리해야 한다 . 바로 이 부분에서 메모리에 대한 이야기가 시작된다 . 데이터베이스 시스템에서 메모리의 주 목적은 I/O 를 방지하는 것이며 따라서 어느 정도까지는 시스템에 메모리가 많을수록 성능이 좋아진다 .최근 몇 년간 메모리 가격이 상당히 낮아져서 수십에서 수백 기가바이트 (GB) 의 RAM 이 장착된 시스템도 생산되고 있다 . 그러나 일반적으로 대부분 애플리케이션의 경우 프로세서 코어당 4GB 에서 8GB 정도가 적당하다 .

AIX구성

좋은 성능을 얻기 위해 변경해야 하는 AIX 매개변수의 수는 상대적으로 적다 . 다음 권장사항은 5.3 이상의 AIX 레벨로 가정한다 . 시스템에 이미 특정 설정이 있는 경우 ( 예를 들면 , BW 또는 SAP 구성 ) 해당 설정은 다음에서 설명할 일반 지침보다 우선시 되어야 한다 .· VMO 매개변수 LRU_FILE_REPAGE 는 0 으로 설정해야 한다 . 이 매개변수는 AIX 가 컴퓨팅 페이지를 희생시킬 ( victimize) 것인지 , 파일 시스템 캐시 페이지를 희생시킬 것인지 여부를 제어한다 . minperm 은 3 으로 설정해야 한다 . 이들은 모두 AIX 6.1 에서 기본값이다 .· AIO 매개변수 maxservers 는 초기에 CPU 당 10 을 기본값으로 남겨둔다 . 시스템이 활성화되면 maxservers 를 다음과 같이 조정한다 .

1. 만약 전체 비동기 I/O(AIO) 커널 프로세스 (aioservers) 가 같은 양의 CPU 시간을 사용중이라면 , ps elfk | grep aio 명령의 실행 결과를 수집한다 .2. 같은 양의 CPU 시간을 사용 중이라면 maxservers 값이 너무 낮게 설정되었을 수 있다 . 이 경우 maxservers 를 10% 늘리고 ‘ 단계 1' 을 반복한다 .3. 일부 aioservers 의 CPU 사용 시간이 다른 aioservers 에 비해 적다면 , 시스템은 적어도 필요한 만큼 많은 aioservers 가 있다 . 10% 이상의 aioservers 가 CPU 를 적게 사용 중이라면 maxservers 를 10% 줄이고 ‘ 단계 1' 을 반복한다 .

· AIO 매개변수 maxreqs 는 MAX(NUM_IOCLEANERS x 256, 4096) 으로 설정해야 한다 . 이 매개변수는 해결되지 않은 AIO 요청의 최대 수를 제어한다 .· hdisk 매개변수 queue_depth 는 어레이의 물리적 디스크 수를 기반으로 해야 한다 . 예를 들어 , IBM 디스크의 경우 queue_depth 의 기본값이 3 이다 . 권장 값은 3 x 장치 대수이다 . 이 매개변수는 대기 가능한 디스크 요청의 수를 제어한다 .· 디스크 어댑터 매개변수 num_cmd_elems 는 어댑터에 연결된 모든 장치에 대한 queue_depth 의 합계로 설정해야 한다 . 이 매개변수는 어댑터에 대기할 수 있는 요청 수를 제어한다 .

Solaris와HP-UX구성

Solaris 또는 HP-UX 에서 DB2 실행을 위해 , 시스템 크기를 기반으로 커널 매개변수를 확인하고 권장하기 위해 db2osconf 유틸리티를 사용한다 . db2osconf 유틸리티는 메모리와 CPU 를 기반으로 또는 현재 시스템 구성이 예상되는 향후 구성과 비교하는 일반 배율 인수로 커널 매개변수를 지정할 수 있다 .SAP 애플리케이션과 같은 대형 시스템을 실행하는 경우 2 이상의 배율 인수를 사용한다 . 일반적으로 db2osconf 는 Solaris 및 HP-UX 를 구성하기에 적합한 출발점을 제공하지만 이 유틸리티가 현재 및 향후 워크로드를 고려할 수 없기 때문에 최적의 값을 제공하지는 않는다 .

Linux구성

DB2 서버로 Linux 시스템을 사용하는 경우 일부 Linux 커널 매개변수를 변경해야 한다 . 왜냐하면 Linux 배포가 변화되고 이러한 환경이 매우 유연하기 때문이다 . 본 글에서는 Linux 구현을 기준으로 확인해야 하는 가장 중요한 일부 설정만을 언급한다 .64 비트 시스템에서 SHMMAX( 공유 메모리 세그먼트의 최대 크기 ) 는 최소 1GB1073741824 바이트로 설정해야 한다 . 반면 SHMALL 매개변수는 데이터베이스 서버에서 사용할 수 있는 메모리의 90% 로 설정해야 한다 . SHMALL 은 기본적으로 8GB 이다 . 기타 주요 Linux 커널 구성 매개변수와 DB2 를 위한 해당 권장 값은 다음과 같다 .

· kernel.sem (SEMMSL, SEMMNS, SEMOPM 그리고 SEMMNI 등 네 개의 커널 세마포 (semaphore) 설정값 지정 ): 250 256000 32 1024· kernel.msgmni ( 메시지 큐 식별자 수 ): 1024· kernel.msgmax ( 메시지의 최대 크기 ( 바이트 )): 65536· kernel.msgmnb ( 메시지 큐의 기본 크기 ( 바이트 )): 65536

다음 회에는 최상의 성능을 위한 구성 중 DB 관련 구성 설정에 대해 알아본다 .

필자소개

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