DMS 파일 컨테이너를 사용한 DB 성능향상    

안녕하세요.  DB2 및 XpertMon 사용자 여러분! ㈜ 아이티엑스퍼트그룹 DB사업부입니다.

현재 저희 XpertMon 개발부서는 고객 분들이 원하시는 사항들을 좀 더 수렴하고 받아드리기 위해 많은 노력을 하고 있으며, XpertMon의 실시간 모니터링을 통해 얻어지는 History를 업무속성(DPF, OLTP, Batch …) 에 따라 적절한 KPI를 적용하여 보다 나은 성능관리 및 튜닝에 힘쓰고 있습니다. 차후 추가되는 기능들에 대해서는 뉴스레터를 통해서 자세하게 말씀 드리도록 하겠습니다.

이번 주는 “DMS 파일 컨테이너를 사용한 DB 성능향상” 에 대해 소개하도록 하겠습니다.

아무쪼록 많은 도움되시길 바라며, 기존 뉴스레터들은 회사 홈페이지 ( www.iteg.co.kr) 게시판에 들어오시면 보실 수 있습니다. 혹시라도 알고 싶은 내용이나 주제가 있다면 메일로 보내주십시오. 참조하여 반영하도록 하겠습니다.

AGENDA

1.      소개

A.        I/O 유형

2.      파일 시스템을 이용한 SMS 또는 DMS 테이블 스페이스의 I/O 모드

A.        Buffer를 이용한 파일 시스템 (File system buffered I/O)

B.        Memory Map을 이용한 파일 시스템 (Memory mapped I/O)

C.       Direct I/O

D.       Concurrent I/O

3.      DB2 UDB 상에서의 DIO 및 CIO 사용하기

A.        테이블 스페이스 단에서 DIO/CIO 설정

B.        파일 시스템 단에서의 설정

4.      DB2 UDB에서 DIO/CIO를 사용하기 위한 AIX ML & Fixes

5.      결론

1. 소개

데이터베이스의 성능 부분에서 많은 부분을 차지 하는 것이 I/O에 대한 부분입니다. 이런 I/O 성능을 향상하기 위한 스토리지 벤더 및 시스템의 변화에 대한 내용을 소개하도록 하겠습니다.

A.     I/O 유형

DB2 UDB V8.2 가 릴리즈 되면서 다음과 같은 세가지 형태의 I/O 유형이 등장합니다.

l        Buffer를 이용한 파일 시스템

l        Memory Map을 이용한 파일 시스템 (only AIX)

l        Raw I/O

위 세가지 형 중 최근까지 성능 상에서 가장 우위에 있던 방식은 Raw I/O를 이용한 방식입니다. 이는 파일 시스템을 사용할 경우 발생하는 caching 및 파일 lock을 피하여, 실제 Disk로부터 바로 Data를 읽어 오는 방식입니다.

그러나, 최근 몇 년 사이 파일 시스템 Vendor에 의해 DIO (Direct I/O) 라는 새로운 I/O 메커니즘의 등장으로 기존의 Raw I/O에 대한 도전장을 제출하였습니다. 파일 시스템의 강점인 관리의 편의성을 중요시 하면서 Raw I/O와 비슷한 형태로 파일 시스템 사용시 발생하는 caching 및 파일 lock을 최소화 할 수 있게 된 것 입니다. 추가로 AIX 5.2.10 버전이 릴리스 되면서 등장한 CIO(Concurrent I/O)는 JFS2 파일시스템을 통해 Raw I/O에 상응하는 성능을 보이게 되었습니다.

2. 파일 시스템을 이용한 SMS 또는 DMS 테이블 스페이스의 I/O 모드

A.     Buffer를 이용한 파일 시스템 (File system buffered I/O)

 가장 일반적인 파일 시스템 사용 방법으로 Process가 File부터 Data를 읽어 오고자 할 때, Disk에서 바로 읽어 오는 거이 아니라 File System Buffer Cache 를 거쳐서 Main Memory로 Data가 Loading 된 후에 읽혀 지는 방식입니다.

 File에 대해 데이터 읽기(read) 요청이 들어온 경우, 파일시스템은 우선적으로 파일 시스템 Buffer cache에 데이터 처리를 요청하게 됩니다. 만일 Buffer cache에 Data가 들어 있지 않을 경우, Disk로부터 Data를 읽어 Buffer cache에 담아 둔 후 처리를 하게 됩니다.

다음 그림은 파일 시스템 버퍼를 통한 읽기(Read) 단계를 보여 주고 있습니다.

File cache를 이용한 파일 기록(write)은 Disk에 대한 Write 발생빈도를 줄일 수 있도록 합니다. 이 같은 방법을 취하게 되면, 파일 쓰기 동작이 비동기적으로 발생하게 되는데 이를 통해 Data가 Disk에 Write 되는 동안 발생할 수 있는 대기상태(Wait)를 줄일 수 있게 됩니다.

다음 그림은 File System Buffer Cache를 통한 쓰기(Write) 동작의 단계를 보여 주고 있습니다.

File System Buffer Cache의 I/O 성능을 향상 시키기 위해서는 시스템의 메모리 소비가 늘어나게 되는 단잠이 있습니다.

이를 대비하기 위해 AIX의 확장 JFS(JFS2)의 경우 시스템 관리자가 최대 사용 가능한 File System Buffer Cache 값을 지정할 수 있습니다.

(maxclient% Parameter이용: Real Memory에서 사용할 수 있는 최대 File System Buffer Cache Ratio (%))

B.      Memory Map을 이용한 파일 시스템 (Memory mapped I/O)

 Memory Map I/O(MMAP I/O) 방식은 파일에 있는 Data를 프로세스(DB2 agent 등)의 Address Space의 Mapping을 통해 접근하는 방법입니다.

Memory Map을 이용할 경우, File에 대해서 동시에 읽기(read)와 쓰기(write)를 동시에 처리할 수 있도록 되어 있습니다.. JFS2인 경우는 MMAP I/O와 DIO를 같이 사용할 수 없도록 되어 있습니다.

 MMAP I/O 방식을 통한 파일 시스템 컨테이너를 사용할 경우, 성능 향상을 위해 파일 시스템 마운트(mount) 시 cio 및 dio 를 “사용하지 않음” 으로 설정해 주어야 한다. DB2 UDB에서는 레지스트리 변수인 DB2_MMAP_READ 와 DB2_MMAP_WRITE를 통해서 MMAP I/O 방식을 사용할 지 결정합니다. (V9.5 이상부터는 DB2 Process가 Thread 구조로 이루어지므로, 위의 DB2_MMAP_READ, DB2_MMAP_WRITE Registry 변수를 Setting 하더라도, 아무런 영향이 없습니다.)

C.     Direct I/O

 만일 순차적으로 Data를 계속 읽어 오는 Application이 실행되고 Buffer를 사용한 File System인 경우, File Buffer Cache로부터 읽혀지는 Data Ratio가 많지 않게 되어 Buffer사용이 무의미 해지게 됩니다. 더욱이 DB2 UDB의 경우 “Bufferpool” 이라는 Data Cache를 따로 가지고 있기 때문에 File System Buffer Cache를 사용한다는 것은 파일로부터의 Data를 File Buffer Cache로 읽어온 후 다시금 Application Buffer로 Data를 옮기게 되는 Double-Copying 이 발생하게 됩니다. 이 중 File System Buffer Caching을 사용하지 않고, 바로 Application Buffer로 Disk의 Data를 옮겨 주는 것이 Direct I/O 방식입니다. (AIX의 경우, JFS 및 JFS2 동시에 DIO 사용가능)

 Direct I/O의 동작은 다음 그림과 같습니다.

D.    Concurrent I/O

Buffered I/O와 Direct I/O가 가지는 단점은 File에 대한 inode-lock과 write-lock이 발생한다는 것입니다. 파일 시스템의 구조상 데이터 무결성과 오류 처리에 있어선 따라와야 하는 문제이며, 이는 데이터베이스 어플리케이션 수행 시 병목 현상을 초래하게 됩니다.

Inode-Lock 이란 파일에 대한 소유자, 권한 및 최종 수정 여부에 대한 정보가 기록된 inode의 값이 파일의 변경과 함께 inode 값을 변경하기 위해 다른 어플리케이션이 이 파일에 inode를 변경할 수 없도록 inode 값을 보호하기 위한 lock을 말합니다. 이 같은 inode lock을 피할 수 있다면 파일에 대한 동시 사용 성능을 높일 수 있는 것입니다.

  JFS2 파일 시스템 상에서 두 개의 Thread가 동시에 공유된 파일에 대해 접근을 한 경우, read에 대해서는 아무 무리 없이 동시 수행을 할 수 있으나, Thread2에 의한 Write 수행 시 Thread1은 잠시 대기 상태로 머무르게 됩니다.

AIX 5.2 ML 01 이후로 Concurrent I/O (CIO) 옵션이 제공 되었습니다. CIO를 사용하게 되면 inode lock 발생으로 인해 생기는 overhead를 줄이기 위해 기존의 읽기 및 쓰기에 대해서는 inode에 shared lock 모드를 발행하였다가, 파일에 대한 크기 변경(extend), 삭제(truncate), 권한 변경 등이 발생할 경우 lock 모드를 write-exclusive lock 으로 변경한다는 것입니다.

CIO 상에서의 Inode lock 방식을 확인해 보면, 파일에 대한 Read-Write는 동시에 수행되는 것을 볼 수 있으나, 파일의 크기가 변경되는(extend, truncate) 발생 시에는 inode lock이 shared lock에서 write exclusive로 상향 조정 됩니다. 이 경우에만 파일에 대한 동시 사용이 이루어지지 않고, 이후엔 다시 파일에 대한 동시 사용이 가능해 지도록 되어있습니다. 이를 통해 CIO를 사용할 시 Raw I/O에 상응하는 성능을 발휘할 수 있는 것 입니다.

3. DB2 UDB 상에서의 DIO 및 CIO 사용하기

 CIO를 사용하기 위해서는 기본적으로 사용되는 MMAP I/O 기능에 대해 사용하지 않음으로 설정해야 하는 사전정의 작업이 필요하게 되어 있습니다. 이 작업에 대해서는 DB2 UDB V 8.2로 들어오면서 DB2_MMAP_READ와 DB2_MMAP_WRITE 레지스트리 변수가 기본적으로 CIO 모드를 사용할 수 있도록 되어 있어 별도의 확인 작업이 필요 없습니다.

A.     테이블 스페이스 단에서 DIO/CIO 설정

CREATE/ALTER TABLESPACE 문에 새로이 추가된 NO FILE SYSTEM CASHING 과 FILE SYSTEM CASHING 옵션을 통해 DIO 및 CIO에 대한 사용 설정을 할 수 있도록 되었습니다.

             예 1. CREATE TABLESPACE <tablespace name> …

이 경우 기본적으로 FILE SYSTEM CASHSING 옵션이 활성화 되어 버퍼를 이용한 I/O 모드로 실행되게 됩니다.

예 2. CREATE TABLESPACE <tablespace name> … NO FILE SYSTEM CASHING

            특정 테이블 스페이스에 한해서 파일 caching 기능을 OFF 하도록 할 수 있습니다.

             예 3. ALTER TABLESPACE <tablespace name> … NO FILE SYSTEM CASHING

사용자가 테이블 스페이스 단에서 I/O 모드를 변경하는 것으로 이 때, 해당되는 테이블스페이스의 모든 컨테이너에 동일한 모드가 적용됩니다.

단, 이 명령을 발행하기 위해서는 데이터베이스에 연결된 어플리케이션이 존재하지 않아야 합니다.

다음의 경우는 NO FILE SYSTEM CASHING 옵션이 적용도지 않습니다.

l          SMS large file (LF)

l          SMS large object files (LOB)

l          SMS/DMS temporary tablespaces

B.     파일 시스템 단에서의 설정

 JFS 나 JFS2 파일 시스템의 경우 마운트(mount) 시 옵션을 통해 DIO/CIO 사용을 설정할 수 있습니다.

 파일 시스템에 대해 -o dio/cio 옵션을 부여하는 경우 파일 시스템 내에 생기는 모든 파일에 대해서 DIO/CIO가 기본적으로 적용됩니다.

4. DB2 UDB에서 DIO/CIO를 사용하기 위한 AIX ML & Fixes

5. 결론

 테이블스페이스 컨테이너를 파일로 사용할 경우 CIO/DIO를 이용하는 것이 일반 적인 파일 시스템 사용에 비해 적은 CPU 및 메인 메모리의 사용량을 줄일 수 있으면, Raw 컨테이너와 비슷한 수준의 성능이 나타나게 됩니다.

 이를 기반으로 DB2 V9.5부터는 NO FILE SYSTEM CASHING 옵션이 기본으로 적용됩니다.

l         참고 자료

Improve database performance on file system containers in IBM DB2 UDB V8.2 using Concurrent I/O on AIX

http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-04081ee