Part 1: Linux에서 실행되는 Oracle8i에서 손쉽게 성능을 높일 수 있는 몇 가지 방법

다른 많은 이들과 마찬가지로 저 또한 Linux의 빠른 성장에 완전히 매료되었습니다. 이는 제가 UNIX에 좀더 많은 기반을 둔 DBA이기 때문만은 아니며, Dell, HP/Compaq, IBM 및 Oracle과 같은 주요 공급 업체들이 놀랄 만큼 빠른 속도로 이 공개 소스 운영 체제를 받아 들이고 있기 때문입니다. 지난 7월에 있었던 LinuxWorld에서 Larry Ellison은 올해 말까지 Oralce의 모든 내부 비즈니스 시스템이 Linux 클러스터에서 실행되도록 전환할 것이라고 발표하여, Linux가 단지 일시적인 유행이 아님을 증명했습니다.

하지만 아직도 Oracle8i를 실행하고 있으며 RAC(Real Application Clusters)에 대한 준비가 제대로 되어 있지 않다면 어떻게 해야 할까요? 기업 환경에서 Oracle 데이타베이스를 실행하고 있는 경우라면 특히나 인텔 기반 Linux 서버를 구축할 때에는 "마지막 한 방울까지 모든 성능을 완전히 다 짜내야" 합니다. 하지만 Linux에 맞게 적절히 튜닝하고 데이타베이스를 구성하면 데이타베이스 성능을 1,000% 향상시키는 것은 아주 쉬운 일입니다.

본 자료에서는 투자 대비 회수율(ROI)을 높이는 몇 가지 방법에 대해 다루겠습니다. 업계 표준 TPC(Transaction Processing Performance Council) 벤치마크 테스트에서 테스트 데이타베이스의 로드 시간이 1,015%, 초 당 트랜잭션 수가 45% 이상 향상된 것을 볼 수 있을 것입니다. 이는 똑같은 하드웨어에서 데이타 로드는 10배, 그리고 트랜잭션 속도는 거의 2배가 빨라진 것입니다. 본 시리즈의 Part 2에서는 이만큼 확실하게 눈에 드러나지는 않지만 좀 더 어려운 테크닉에 대해 다룹니다.

벤치마킹 설정

기준을 정할 수 있도록 제어 환경을 사용하여 튜닝 테크닉을 평가하고 변경 가능한 모든 관련 변수를 확인한 다음 그 변수를 한 번에 하나씩 수정하여 그 변화에 따른 영향을 확실하게 측정하려고 합니다.

테스트 환경에서는 512MB 메모리, 7,200 rpm Wide-Ultra SCSI 드라이브 8개가 장착된 Compaq 4-CPU 서버를 사용했습니다. 그리고 동일한 메모리에 7,200 rpm ultra 100 IDE 드라이브를 하나만 장착한 단일 CPU Athlon 시스템에서도 동일한 테스트를 실행했습니다. 그 결과 비록 실제 수치와 비율은 동일하지 않았지만 그 향상 패턴은 동일하다는 것을 알 수 있었습니다. 즉, 모든 테스트에서 각 시스템의 성능은 동일한 경향을 보이며 향상되었으며 향상 규모 또한 비슷했습니다.

Linux 서버는 유연성이 뛰어나므로 웹, 애플리케이션, 데이타베이스, 전자 메일, 파일 및 프린터 서버와 라우터, 방화벽 등 그 어느 것으로도 손쉽게 이용할 수 있으며, 두 가지 역할을 동시에 할 수도 있습니다. 하지만 이 테스트에서는 단일 변수 요건을 충족시키기 위해 단 한 가지 용도만 선택하겠습니다. 다른 용도는 다음 자료에서 살펴 보겠습니다.

단순하게 하기 위해 이 테스트에서는 TPC-C 벤치마크를 사용했습니다. 이 방법은 신뢰도 높은 온라인 트랜잭션 프로세싱(OLTP) 작업 로드 벤치마크로 널리 알려져 있으며, 온라인 및 지연된 트랜잭션을 모두 처리합니다. 그리고, 전혀 일정하지 않으며 Oracle 데이타베이스의 모든 릴리스를 포함한 다양한 데이타베이스에 적용됩니다. 이 외에도 CPU, 메모리, 드라이브 등 하드웨어의 모든 측면을 강조하도록 TPC-C를 구성할 수도 있습니다. 솔직히 말하자면 저는 Quest Software의 DBA이며, 이 회사에는 전자 메일을 전송하는 것 만큼이나 쉽게 TPC 테스트를 정의, 실행 및 측정하는 Benchmark Factory라는 유용한 툴이 있습니다. 그림 1은 Benchmark Factory의 인터페이스로, 이를 통해 TPC-C 벤치마크 프로젝트를 만들고 데이타베이스 크기, 동시 사용자 수 등의 매개변수를 정의하며 측정하고자 하는 테스트를 실행 대기열로 복사하고 대기열에 있는 테스트를 실행한 다음 그 결과를 관찰할 수 있습니다.

그림 1: Benchmark Factory 인터페이스

앞서 ROI가 높은 방법들을 살펴 보겠다고 말했는데요, 이는 응용 가능성 및 미치는 영향 면에서 아주 알기 쉽고 확실한 항목들을 찾아 볼 것이라는 뜻이므로 TPC-C에서 런타임 차이만 확인하면 됩니다. 따라서, 운영 체제 및 데이타베이스 부분에서 "손쉽게 얻을 수 있는 열매"만 살펴 보겠습니다. 다음 설명서에서는 free, iostat, ipcs, mpstat, sar, top, vmstat 등과 같은 Linux 툴이 필요한 변경 사항들에 대해 자세히 다룰 예정입니다.

다음 섹션은 데이타베이스 구성 및 튜닝 문제에 대한 것으로서 많은 DBA들이 이미 알고 있는 간단한 내용일 수 있습니다. (하지만 그렇게 간단하지만은 않은 문제일 수 있습니다.)

Database Server에서 쉽게 얻을 수 있는 성능상의 이익(쉽게 얻을 수 있는 열매)

먼저 일반적인 초기 데이타베이스부터 살펴보겠습니다. 사람들은 보통 Oracle Installer에서 만들어진 기본 데이타베이스나 Database Configuration Assistant를 사용해 만든 데이타베이스를 사용하는 경우가 많습니다. 어느 경우나 그 기본 설정은 일반적으로 거의 쓸모가 없습니다. 더구나 초보 DBA나 DBA를 사칭하는 컨설턴트들은 문제를 더욱 복잡하게 만드는 값을 선택할 지도 모릅니다. 즉, 잘못된 초기화 매개변수를 사용해 설정되거나 표 1처럼 딕셔너리 테이블스페이스를 사용하는 데이타베이스가 많다는 것입니다.

표 1: 일반적인 초기 데이타베이스 설정

TPC-C 결과(기준)

가장 먼저 선택할 수 있는 방법은 SGA 크기를 늘리는 것이므로 표 2와 같이 버퍼 캐시와 공유 풀을 늘리겠습니다.

표 2: 퍼버 캐시와 공유 풀 크기 증가

TPC-C 결과

기대와는 달리 로드 시간은 1.73%, 그리고 트랜잭션 속도(TPS)는 10.88%밖에 향상되지 않았습니다. 아마도 SGA 리두 캐시도 높여야 했던 것 같습니다. 그리고 리두 로그 파일이 SGA 메모리 할당보다 작은 것은 원치 않으므로 리두 로그 파일 크기도 이에 맞춰 표 3과 같이 높이겠습니다.

표3:SGA 리두 캐시와 리두 로그 파일 크기 증가

TPC-C 결과

이제 어느 정도 된 것 같군요. 로드 시간이 10배나 늘어난 17.35% 향상되었습니다. 그리고 이번에도 트랜잭션 속도는 이전과 비슷하게 9.33% 향상되었습니다. 로드와 동시 삽입, 업데이트 및 삭제 작업에는 8MB보다 훨씬 더 많은 공간을 필요하므로 이는 당연한 결과입니다. 하지만 메모리 증가가 성능을 아주 조금밖에 향상시키지 못하는 것 같아 보이며, 문제는 I/O 때문인 것 같습니다. 따라서 OLTP 시스템을 사용하고 있음에도 불구하고 표 4와 같이 블 록 크기를 높여 보겠습니다. .

표4: 블록 크기를 4K로 증가

TPC-C 결과

이제 효과가 나타나고 있습니다. 버스와 I/O 기능이 제한되어 있는 PC라 하더라도 블록 크기를 높이면 상당한 효과를 얻을 수 있습니다. 로드 시간이 138% 이상 향상되었으며 TPS는 전혀 손상되지 않았습니다. 일단 블록 크기는 더 이상 늘리지 않기로 하자 그 다음 떠오른 생각은 테이블스페이스를 딕셔너리에서 로컬 관리로 전환하자는 것이었습니다. Oracle이 로컬 관리 테이블스페이스를 상당히 끈질기게 권유했었기 때문입니다. 그 결과 표 5와 같은 결과를 얻었습니다.

표5: 로컬 테이블스페이스 사용

TPC-C 결과

Oracle이 옳았습니다. 로컬 관리 테이블스페이스는 올바른 선택이었습니다. 로드 시간이 15% 이상 향상되었으며 TPS도 약 2% 향상되었습니다. 하지만 4K 블록 사이즈를 적용해서 얻은 것과 같은 성능 향상을 얻고 싶었으며, 그래서 표 6에서처럼 8 K를 시도했습니다.

표6:블록 크기를 8K로 증가

TPC-C 결과

그리 나쁘진 않습니다. 앞서와 마찬가지로 블록 크기를 높이자 로드 시간은 (거의 32%) 향상되었으며 TPS는 전혀 손상되지 않았습니다. 사실, TPS는 2% 이상 향상되었지만 블록 크기 증가에 있어서 아주 중요한 시점에 도달했다는 사실에 주목해야 합니다. 로드 시간 증가가 138%에서 32%로 상당히 줄었으며 TPS는 4K 블록 크기의 경우보다 거의 3배나 늘었습니다. 따라서 블록 크기를 더 높이는 것은 좋은 방법 같아 보이지는 않습니다. 다른 성능 측정 툴을 사용할 필요가 없다는 것은 너무나 자명한 사실입니다.

이제 데이타베이스에서 쉽게 얻을 수 있는 열매는 거의 다 따가는 것 같군요. 이제 시도할 수 있는 방법은, 다중 CPU를 가지고 있으니까 표 7과 같이 I/O 슬래이브를 설정해서 그 CPU를 이용해 보는 방법입니다.

표7: I/O 슬래이브 이용

TPC-C 결과

로드 시간이 9% 더 향상되었지만 TPS는 거의 그대로입니다. 이제 거의 다 온 것 같습니다. 지금까지 로드 시간은 342%, TPS는 24% 향상되었으며, 광범위하고 자세한 성능 모니터링이 전혀 필요하지 않았으므로 좋은 결과라고 할 수 있습니다. 다음은 이 결과를 요약한 것입니다.

Linux에서 쉽게 얻을 수 있는 열매

이제 Linux의 성능 향상에 대해 살펴보겠습니다. Linux는 제조 업체, CPU 속도 및 개수, 시스템 메모리 양, 드라이브 유형과 속도 및 개수 등의 하드웨어 상태를 스스로 파악하여 적응하는 능력이 있습니다. 그럼에도 불구하고 손쉬운 성능 향상 방법이 여전히 많이 남아 있습니다. 먼저 일반적인 Red Hat Linux 6.2를 설치하는 것부터 시작하도록 하겠습니다. (참고: Linux 6.2에 함께 제공되는 커널 2.2.14-5smp부터 시작하겠습니다.)

Linux 설치가 끝나면 맨 먼저 단일 커널을 만들어야 합니다. 즉, 사용하고자 하는 라이브러리를 정적으로 포함시키고 로드된 모듈을 정적으로 해제하도록 커널을 재컴파일합니다. 필요한 기능만 갖춘 가벼운 커널은 필요하지 않은 기능까지 지원하는 무거운 커널보다 우수하기 때문입니다. 이제 cd 명령을 사용해 디렉터리를 /usr/src/Linux로 바꾸고 make clean xconfig 명령을 내리겠습니다(X -Window System이 아니라 이 명령줄로 부팅했음).

이제 말 그대로 수 백 개의 매개변수를 설정해야 합니다. 이에 대해 참조할 만한 책이나 웹 사이트가 10여 개 있습니다. 이 중 제가 가장 많이 이용하는 것은 Gerhard Mourani가 쓴 Securing and Optimizing Linux: Red Hat Edition입니다. 아니면 Mourani 책의 오래된 PDF 버전을 다운로드받을 수도 있으며, Linux에 대한 다른 권장 도서를 보려면 OTN Members Booklist on Amazon을 참조하십시오.

제 머리에 떠오른 몇몇 매개변수 설정들은 CPU 유형, 대칭 멀티프로세싱(SMP) 지원, APIC(Advanced Programmable Interrupt Controller) 지원, DMA(Direct Memory Access) 지원, IDE DMA 기본 사용, 할당량 지원 등입니다. 이 매개변수 설정을 모두 처리한 다음 그래도 자신이 없다면 xconfig 도움말 파일을 읽어 보는 것이 좋습니다.

커널을 재컴파일할 계획이므로 Oracle 데이타베이스 설치 가이드의 설명에 따라 내부 처리 통신(PIC) 설정도 수정하는 것이 좋습니다. 2.2 커널의 경우에는 공유 메모리 설정이 /usr/src/Linux/include/asm/shmparam.h에 있습니다. SHMMAX 매개변수 값을 최소한 0x13000000 이상으로 설정하는 것이 좋습니다. 세마포(semaphore) 설정은 /usr/src/Linux/include/Linux/sem.h에 있으며, SEMMNI, SEMMSL, SEMOPN는 각각 최소한 100, 512, 100 이상으로 설정하십시오.

이제 make dep clean bzImage 명령을 사용해 커널을 재컴파일하고 그 링크맵과 커널 이미지를 부팅 디렉터리 edit /etc/lilo.conf로 복사한 다음 lilo를 실행한 후 재부팅하겠습니다. 모든 것을 정확하게 실행했다면 이제 컴퓨터는 보다 날씬하면서도 더욱 우수한 새 커널을 사용해 부팅될 것입니다.

IPC 설정 크기가 적절하게 조절된 이 단일 커널은 표 8에서 볼 수 있듯이 로드를 거의 10% 향상시켰으며 TPC도 거의 7% 향상되었습니다.

표8: IPC 설정 크기가 적절히 튜닝된 단일 커널을 사용한 TPC-C 결과

커널의 특정 버전을 재컴파일하기만 해도 이러한 성능 향상을 얻을 수 있다면 같은 커널 제품군의 새 버전도 성능 향상을 제공할 수 있을 것이라고 추론할 수 있습니다. 그래서 Linux Online에서 같은 제품군 중 가장 최신의 안정적인 커널 소스(여기서는 2.2.16-3smp)를 받았습니다. 하지만 그 결과는 표 9에 제시된 것처럼 로드 향상은 1.5%에 그쳤으며 TPS는 실제로 전혀 향상되지 않았습니다.

표9: 새로운 마이너 버전 커널을 사용한 TPC-C 결과

현재 많은 Linux 분산이 커널 2.4.x를 베이스로 사용하고 있으므로 이번에는 이 버전을 시도해 보았습니다. 그래서 커널 소스 2.4.1smp를 다운로드했습니다(2.4.7이 현재 가장 널리 사용되고 있는 안정적인 릴리스임). 이 새 커널은 기다린 보람이 있어서 표 10에 제시된 것처럼 로드 시간은 거의 13% 그리고 TPS는 10% 이상 향상되었습니다.

표10:새로운 주요 버전 커널을 사용한 TPC-C 결과

이 결과도 나쁘진 않지만 OS를 조정하면 데이타베이스를 조정한 경우처럼 커다란 성과를 낼 것이 틀림 없었습니다. 또한 다양한 데이타베이스 매개변수를 조정한 경험을 통해 전 블록 크기나 로컬 관리 테이블스페이스처럼 I/O를 줄이는 항목이 커다란 성능 향상을 가져온다는 것을 알게 되었습니다. 그래서 저는 I/O를 줄이는 Linux 테크닉을 찾아내는 것을 목표로 했습니다. 기본적으로 Linux는 읽기 작업 시 모든 파일의 마지막으로 읽은 시간 속성을 업데이트하며 쓰기 작업의 경우에도 동일한 작업을 합니다. 하지만 Oracle 데이타베이스가 그 데이타 파일을 언제 읽는지는 제게 전혀 중요한 문제가 아니므로 이 기능을 껐습니다. 이것을 noatime 파일 속성 설정이라고 합니다(Windows NT, 2000, XP에도 비슷한 설정이 있음. regedit를 사용해 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate를 설정).

Oracle 데이타 파일에만 이러한 설정을 하려면 chattr +A file_name 명령을 사용하십시오. 그리고 모든 디렉터리에 이 설정을 하려면 명령은 chattr -R +A directory_name이 됩니다. 하지만 가장 좋은 방법은 각 항목 마다 /etc/fstab 파일을 편집하고 파일 시스템 매개변수 목록(네 번째 열)에 noatime 키워드를 추가하는 것입니다. 다음은 /etc/fstab 파일을 이렇게 변경한 예입니다.

LABEL=/   /      ext2  defaults,noatime 1 1
LABEL=/boot /boot    ext2  defaults,noatime 1 2
none    /dev/pts  devpts gid=5,mode=620  0 0
none    /proc    proc  defaults     0 0
none    /dev/shm  tmpfs  defaults     0 0
/dev/hda2  swap    swap  defaults     0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro  0 0
/dev/fd0  /mnt/floppy auto  noauto,owner   0 0

이렇게 하면 파일 시스템의 모든 설정이 이익을 얻을 수 있으며, 더욱 중요한 것은 재부팅할 경우에도 이 설정이 그대로 유지된다는 것입니다. 이렇게 변경한 결과 표 11에 제시된 것처럼 로드 시간의 경우 거의 50%, TPS의 경우 8% 향상이라는 엄청난 효과를 얻었습니다.

표11: noatime 파일 속성을 사용한 TPC-C 결과

I/O와 관련된 또 다른 부분은 Linux 가상 메모리 부속 시스템으로, Linux의 다른 많은 부분과 마찬가지로 이 부분도 컨트롤이 가능합니다. 파일 시스템 성능을 높이려면 /ect/sysctl.cong 파일을 편집하고 다음 한 항목을 추가하기만 하면 됩니다.

vm.bdflush = 100 1200 128 512 15 5000 500 1884 2

여기에서, /usr/src/Linux/Documentation/sysctl/vm.txt에 따르면 각 매개변수는 다음과 같습니다.

• " 첫 번째 매개변수는 버퍼 캐시에 있는 더티 버퍼의 최대 수를 관리합니다. 더티 버퍼란 그냥 잊어버리면 되는 클린 버퍼와는 반대로 그 버퍼의 내용을 디스크에 써야 한다는 것을 뜻합니다. 이 매개변수를 높은 값으로 설정한다는 것은 Linux가 디스크 쓰기를 오랫동안 지연할 수 있다는 것을 뜻하며, 따라서 한 번에 많은 I/O를 실행해야 하므로 메모리가 부족해진다는 것을 뜻합니다. 이 매개변수 값이 낮으면 디스크 I/O가 보다 균일해집니다.

• " 두 번째 매개변수는 1200 ndirty로, bdflush가 한 번에 디스크에 쓸 수 있는 더티 버퍼의 최대 수를 제공합니다. 값이 크면 지연되어 I/O가 꽉 차게 되는 반면 이 값이 작으면 bdflust가 충분히 자주 작동하지 않을 경우 메모리 부족을 유발할 수 있습니다.

• " 세 번째 매개변수는 128 nrefill로, refill_freelist()가 호출될 때 bdflust가 사용 가능한 버퍼 목록에 추가하는 버퍼의 수입니다. 버퍼가 메모리 페이지와는 크기가 다른 경우가 종종 있으며 일부 기록 작성은 미리 해야 하는 경우도 있으므로 사용 가능한 버퍼를 미리 할당해야 합니다. 이 값이 클수록 낭비되는 메모리도 많아지며 값이 작으면 refill_freelist()를 실행해야 하는 경우가 종종 있습니다.

• " 네 번째 매개변수는 512 refill_freelist()입니다. 이 매개변수 값이 nref_dirt 더티 버퍼보다 크면 bdflust가 실행됩니다.

그 결과, 표 12에 제시된 것처럼 로드 시간은 26%, TPS는 7% 향상되었습니다.

표12: bdflust를 설정한 TPC-C 결과

이 최종 결과에 따르면, 이전에는 50초가 걸렸던 작업을 로드하는 데 5초도 걸리지 않았으며, TPS도 거의 두 배로 향상되었습니다. 그리고 이 과정에서 제가 아무것도 모니터링하지 않았다는 것에 주목해야 합니다. 이 결과는 전혀 복잡한 과정을 거치지 않고 마치 낮게 매달려 있는 과일을 따는 것만큼이나 쉬우면서도 확실한 성능 향상을 얻을 수 있습니다.

다음은 모든 테스트 결과를 요약한 것입니다.

결론: Linux + Oracle8i Database= 속도

결론

Linux와 Oracle Database Server는 파워와 구성 가능성 면에서 완벽하게 조화를 이룹니다. 하드웨어에서 가능한 최적의 성능을 이끌어내기 위해서는 이 둘이 잘 균형을 맞추도록 조정해야 하며, 올바른 툴과 방법을 이용한다면 그리 어려운 작업은 아닙니다. 성능이 이렇게 향상되면 애플리케이션이 몇 배는 더 빠르게 실행될 수 있습니다. 따라서 Linux나 Oracle Database를 절대 기본 설치 상태 그대로 사용하지 마십시오. 단 몇 분의 노력이면 시스템이 노래를 부르도록 만들 수 있습니다.

Bert Scalzo ( Bert.Scalzo@Quest.com)는 캘리포니아 주 Irvine에 위치한 Quest Software의 제품 설계자입니다. 이 회사는 중요한 비즈니스 애플리케이션의 가용성을 최대화할 수 있고 ROI를 신속히 회수할 수 있는 애플리케이션 관리 솔루션을 제공합니다. Bert는 컴퓨터 공학 박사 학위를 가지고 있으며, Oracle Database 릴리스 4부터 Oracle DBA로 활동해 왔고 현재는 Oracle9i Database 작업을 하고 있습니다.

원본 : http://otn.oracle.co.kr/tech/column/2003/scalzo_linux01.html