2016년 7월 28일 목요일

[Tuning] Oracle Tuning

최적화의 중요성 (The Importance of Tuning)


Oracle8은 상당히 최적화되어 있는 소프트웨어 제품이다. 종종 튜닝을 통해 시스템 퍼포먼스를 최적화 하고 자료 병목현상을 막아야 한다. 비록 이 장에서는 단일 프로세서 (single-processor) 시스템을 기준으로 기술되어 있지만, 오라클의 병렬 옵션을 이용하는 시스템에 관한 대부분의 퍼포먼스 튜닝 팁도 여기서 제공된다.

시스템을 튜닝하기 전에 (Before Tuning the System)


시스템을 튜닝하기 전에, 다음장의 "LINUX Tools"에 기술된 리눅스 툴의 정상적인 동작법을 익혀 두어야 한다.
See Also:
Oracle8 병렬 서버 개념과 관리 (Oracle8 Parallel Server Concepts and Administration).
Oracle8 Tuning.


LINUX Tools


리눅스는 데어터베이스 접근의 퍼포먼스를 관찰하고 요구되는 데어터베이스를 결정하는 등의 퍼포먼스 모니터링 툴을 제공한다.
oracle process들의 통게를 제공할 뿐만아니라, 이들은 CPU 이용률, 인터럽트, 스와핑, 페이징, 그리고 전체 시스템을 위한 context switching 등에 대한 통계도 제공한다.
See Also:
리눅스 톨들은 운영체계 문서에 기술되어 있다. 


vmstat


vmstat 유틸리티는 리눅스 상에서 process, virtual memory, disk, paging, CPU 활동도 등을 알려준다. 다음 문장은 시스템 활동도에 대한 요약을 5초 간격으로 8번 보여 준다:
% vmstat -n 5 8

vmstat 명령의 예제 출격이 다음 Figure 3-1에 보여주고 있다.
w column (procs 아래의)은 swap out(디스크로 쓰여진) 되어져 나간 프로세스의 수를 의미한다. 만약 값이 0이 아니라면, 스와핑이 일어 났다는 것을 의미하여 여러분의 시스템은 메모리 부족이 있다는 것을 의미한다. si와 so columns은 각각 초당 swap-ins과 swap-outs의 수를 표시한다. Swap-outs은 거의 항상 0일 것이다.

Figure 3-1 Output from the vmstat -n command

procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 16124 964 524 29904 2 14 13 21 208 3 9 4 87 1 0 0 16124 648 524 30140 0 0 1 0 806 1763 5 8 87 1 0 0 16124 608 524 29904 0 0 0 0 856 1894 5 7 87 0 0 0 16124 612 524 29624 0 0 0 5 734 1586 5 8 88 2 0 0 16124 1656 520 28296 0 0 221 0 687 1395 14 10 77 0 0 0 16124 840 520 29060 0 0 38 0 621 1287 3 4 93 0 0 0 16124 856 520 29196 0 0 0 0 647 1395 4 6 91 1 0 0 16124 708 520 29288 0 0 1 0 618 1287 3 4 93

free


free utility는 스왑 공간 이용률에 관해 알려준다. 스왑공간이 모자랄 경우 시스템이 중단되던지 응답시간이 느려지게 된다.

SQL Scripts


utlbstat 와 utlestat SQL Scripts


utlbstat 와 utlestat SQL scripts는 오라클 데이터베이스 퍼포먼스와, Shared Global Area (SGA) 자료구조를 모니터 하는데 이용되는 프로그램이다. 이 스크립트에 관한 정보는 Oracle8 Server Tuning를 참조하기 바란다. 리눅스상에서, 이 스크립트는 $ORACLE_HOME/rdbms/admin/에 위치해 있다.

메모리 관리 튜닝하기 (Tuning Memory Management)


얼마나 많은 메모리 공간이 필요한지 결정하기 위해서 스와핑과 페이징 공간을 튜닝하는 것으로 메모리 튜닝과정을 시작한다.
오라클 buffer manager는 좀더 자주 접근하는 자료가 좀더 오랫동안 캐시 되어 있도록 되어 있다. Buffer manager와 buffer cache를 모니터링 하는 것은 오라클 퍼포먼스에 상당한 영향을 미친다. 여러분들의 시스템에서 적절한 오라클 버퍼 사이즈는 전반적인 시스템의 부하와 다른 응용프로그램들에 대한 오라클의 상대적인 우선순위의 정도에 달려 있다.

충분한 스왑 공간을 할당하라


스와핑은 리눅스에서 상당한 overhead의 원인이 되기 때문에 최소화 시켜야 한다. 스와핑을 점검하기 위하여 다음 유틸리티들을 이용한다.
free 또는 vmstat -n
만약 여러분들의 시스템이 스와핑이 일어나고 메모리를 유지할 필요가 있다면:
  • 불필요한 시스템 데몬 프로세스 응용프로세스 등을 실행시키지 마라.
  • 어느정도 빈 메모리를 확보하기 위하여 데이터베이스 버퍼 크기를 줄여라.
  • 리눅스 파일 버퍼의 수를 줄여라. 특히 raw 장치를 이용하고 있다면.
스왑공간을 추가하는 것은 구현된 리눅스에 따라 조금씩 다르다. 리눅스상에서 얼마나 많은 스왑 공간이 현재 남아 있는지를 결정하려면 free 유틸리티를 이용한다. 보다 자세한 정보는 리눅스 문서를 참조하기 바란다.
스왑공간의 크기는 여러분들의 RAM 메모리의 2-4배로 시작하라. CASE, 오라클 응용 프로그램 또는 오라클 오피스를 이용하려면 좀더 많은 공간을 필요로 한다. 스왑공간의 사용을 모니터 하다가 필요하다면 스왑공간을 증가시키도록 한다.

Control Paging


프로그램이 실행하기 위해서 전체 프로그램이 모두 다 메모리에 상주하지는 않기 때문에, 페이징(Paging)은 스와핑만큼 심각한 문제로 나타나지는 않는다. 약간의 page-outs은 여러분들의 시스템 퍼포먼스에 유의하게 영향을 미치지는 않는다.
과다한 페이징을 발견하기 위해서, 반응속도가 빠를때 measurements를 실행시켜 두었다가 반응속도가 느려 졌을 때와 비교하도록 한다.
페이징을 모니터하기 위해서 vmstat 또는 free를 이용하도록 하라. vmstat 출력 중 다음 컬럼은 중요하다:
  • vflt/s는 page fault가 나타난 주소변환의 수를 가르킨다. Address translation faults는 프로세스가 참조하고자 하는 주소페이지가 메모리 내에 있지 않을 때 발생한다.
  • rclm/s는 page-out activity에 의해 free list에 추가되고 개정된 유효한 페이지를 말한다. 이 값은 대체로 0이 된다.
만약 여러분들의 시스템이 너무 많은 page-out activity를 보이면, 다음과 같은 해결법을 생각해 보라:
  • 메모리를 증설하라.
  • 일부 작업을 다른 시스템으로 이동하라.
  • 여러분들의 커널을 메모리를 적게 사용하도록 설정하라.

SGA를 단일 공유메모리 세그먼트내에 유지하라.


비록 퍼포먼스상의 이득은 미미하지만, 충분한 공유메모리를 확보하도록 설정하지 않고서는 데이터베이스를 시작할 수 없다.
여러분들은 리눅스 커널의 공유메모리를 증가시키도록 다시 재설정할 필요가 있다. 공유메모리를 위한 리눅스 커널 인자는 SHMMAX, SHMMNI, 그리고 SHMSEG이다. SGA가 단일 공유메모리 세그먼트내에 상주하도록 하려면 SHMAX를 4294967295 (4 GB)로 설정해야 한다.
SGA의 크기는 다음과 같은 단계를 거쳐서 측정할수 있다:
  1. DB_BLOCK_BUFFERS 과 DB_BLOCK_SIZE를 곱하라.
  2. Step 1의 결과를 SORT_AREA_SIZE에 더하라.
  3. Step 2의 결과를 SHARED_POOL_SIZE에 더하라.
  4. Step 3의 결과를 LOG_BUFFER에 더하라.
공유메모리의 상태를 모니터링하기 위하여 리눅스 유틸리티인 ipcs를 이용할 수도 있다.
참조 :
Oracle8 Installation Guide for LINUX의 chapter 2에 있는 "오라클을 위한 리눅스 커널의 설정".


디스크 입출력 튜닝하기 (Tuning Disk I/O)


I/O 병목현상은 가장 쉽게 찾을수 있는 실행상의 문제점이다. 균형잡힌 I/O는 결국 전체 모든 이용가능한 디스크상에서 디스크 접근 시간을 줄이는 것이다. 작은 데이터베이스와 병렬 질의 옵션을 사용하지 않는 곳에서는, 데이타 파일이 다를 경우 테이블스페이스가 이용가능한 디스크 공간내에 분산되어 있는지 확인하도록 한다.

쓰기 대역폭을 넓히기 위해 데이터베이스 Writer를 튜닝하라.


오라클은 database writer (DBWR)가 병목현상을 가지지 않도록 해법을 요구한다:
  • 비동기 입출력(asynchronous I/O)을 이용하라.
  • I/O slaves를 이용하라.

비동기적 입출력 (Asynchronous I/O)


비동기 입출력 (Asynchronous I/O)은 프로세스들이 쓰기를 하고 난후 기다리지 않고 바로 다음 작업으로 진행하도록 해준다. 그렇기 때문에 시스템 퍼포먼스를 높이고 idle time을 줄일수 있게 해 준다. Solaris는 저수준 (raw) 또는 파일 시스템 (filesystem) 데이터 파일 둘다에 대한 비동기 입출력을 지원해 준다.

I/O Slaves


I/O Slaves는 기능이 입출력만을 수행하는 아주 특이화 되어 있는 프로세스이다. Oracle8에서는 처음 등장하는 것이며, 다중 DBWRs (다른 프로세스들 뿐만 아니라)를 대치할수 있다. (사실 multiple DBWRs의 일반적인 형태이며, 다른 프로세스에 의해서 이용될 수도 있다) 그리고 비동기 입출력이 이용할수 있든지 없든지간에 작동한다. I/O Slaves는 그들이 운영하는 중에 조절을 허용하는 초기화 인자를 제공한다. 그들은 Table 3-1에 기술되어 있다.
Table 3-1 I/O Slaves를 위한 초기화 인자
Parameter  Range of Values  Default Value  
DISK_ASYNCH_IO
TRUE/FALSE
TRUE
TAPE_ASYNCH_IO
TRUE/FALSE
TRUE
BACKUP_DISK_IO_SLAVES
TRUE/FALSE
FALSE
BACKUP_TAPE_IO_SLAVES
TRUE/FALSE
FALSE
DBWR_IO_SLAVES
0 - 999
0
LGWR_IO_SLAVES
0 - 999
0
ARCH_IO_SLAVES
0 - 999
0
DB_WRITER_PROCESSES
1-10
1

비동기 입출력이 필요하지 않든지 또는 불가능할 경우가 있다. Table 3-1에 있는 처음 두개의 인자, DISK_ASYNCH_IO 와 TAPE_ASYNCH_IO은 디스크와 테이프 디바이스에 대해서 비동기 입출력을 허용할 것인지를 설정하는 것이다. 각각의 프로세스 형에 따라 I/O Slaves의 수는 기본적으로 0으로 설정되기 때문에 특별히 설정을 하지 않으면 I/O Slaves를 이용하지 않는 것으로 간주한다.
DBWR_IO_SLAVES는 ASYNC I/O (즉 DISK_ASYNCH_IO 또는 TAPE_ASYNCH_IO)가 비활성화 되어 있는 경우에만 0보다 큰 값으로 설정된다. 그렇지 않을 경우 DBWR에 병목현상이 나타나게 될 것이다. 이와 같은 경우 리눅스에서 DBWR_IO_SLAVES의 적절한 값은 4 정도가 된다. LGWR_IO_SLAVES가 설정된 경우 9 slaves 이상 설정할 것을 권하지 않는다.
DB_WRITER_PROCESSES는 DB_WRITER인자를 대치한 것이다. 그리고 하나의 인스턴스에 대하여 데이터베이스 writer process의 초기 갯수를 명시하도록 한다. 만약 여러분들이 DBWR_IO_SLAVES를 이용한다면, DB_WRITER_PROCESSES가 어떻게 설정되던지 간에 단지 하나의 데이터베이스 writer process가 이용될 것이다.

Monitoring Disk Performance


디스크 퍼포먼스를 모니터 하기 위하여, vmstat.를 이용하라.
디스크 퍼포먼스를 위해 눈여겨 봐야 할 vmstat 컬럼은, 블럭 입출력(blocked I/O)을 위해 CPU가 대기하는 시간의 퍼센티지를 나타내는 %wio이다.
주요 인디케이터는 (Key indicators):
  • bread, bwrit, pread 와 pwrit의 합계는 디스크 입출력 서브시스템(disk I/O subsystem)의 상태를 가르킨다. 이 합계가 더 클 수록, 디스크 입출력 병목현상의 가능성은 더 커진다. 물리적으로 디스크의 갯수가 많을 수록, 더 큰 역치값(threshold number)을 가지게 될 것이다. 적당한 값은 두개의 드라이브에 대해서는 40을 넘지 않도록 하고, 4개 내지 8개의 드라이브일때는 기본값이 60을 넘지 않도록 해준다.
  • %rcache는 90보다 크야 하며, %wcache는 60 보다 크야 한다 그렇지 않을 경우 시스템의 디스크 입출력은 한계점에 온 것이다.
  • 만약 %wio는 지속적으로 20이상라면 시스템의 디스크 입출력은 한계점에 온것이다.




디스크 퍼포먼스 문제점 (Disk Performance Issues)

댓글 없음:

댓글 쓰기