Sun Developer Network 공식 블로그

본 문서의 정보는 썬 파이어 T2000 서버 상의 솔라리스10과 DB2를 이용해서 메사추세츠 주의 벌링턴에서 썬의 마켓 개발 엔지니어링 팀, 전략 어플리케이션 엔지니어링 팀이 실험한 자료들을 바탕으로 쓰여졌습니다. 테스트들은 다양한 워크로드를 사용하여 최적의 퍼포먼스와 사용하기 간편한 설정을 알아내었습니다. 결과는 각 유저, 환경에 따라 달라질 수 있습니다.

팁들은 썬 파이어 T2000 아키텍쳐에서 솔라리스10에 DB2를 최적으로 배치하고자 하는 시스템 관리자와 DBA들을 위해 제공됩니다.

울트라SPARC T1 프로세서는 쿨쓰레드 기술을 통해 8개의 이상의 코어를 가지고 있고 각 코어당 4개의 하드웨어 쓰레드를 가지고 있어서 프로세서가 동시에 32개 이상의 쓰레드를 처리 할 수 있습니다. 각 코어는 각 클럭 사이클 마다 하나의 하드웨어 쓰레드를 실행 시킬 수 있고, 각 쓰레드는 고유의 레지스터 셋을 가지고 있습니다. 최적화는 각 코어가 프로세서에서 수행되고 있는 어플리케이션 워크로드의 특성마다 1X~4X 까지 확장이 가능합니다. T1 아키텍쳐는 메모리 접근에 의해 낭비되는 사이클을 활용하는 방식으로 최적화 되었습니다. 하드웨어 쓰레드는 만약 특정 명렁에 때문에 문제가 생긴다면 하드웨어에 의해 정지 됩니다. 울트라SPARC T1 프로세서는 이러한 사이클을 이용하여 코어의 다른 하드웨어 서비스를 서비스 합니다. 이것으로 인한 이득은 어플리케이션의 특성마다 틀립니다. 대용량의 데이타셋에 연속적으로 포인터를 추적하는 현대의 상용 어플리케이션들은 좋은 후보자가 될 수 있습니다. 네트워크에 종속적인 데이타셋을 가지고 여러가지 프로세스 혹은 쓰레드에 의해 처리 되는 어플리케이션 또한 울트라SPARC T1 프로세서에서 확장성이 좋습니다.

썬 파이어 T2000 은 처리량 퍼포먼스, 에너지 효율성, 계산의 집적성에 관한 업계의 표준을 만들었습니다. 썬 파이어 T2000 서버는 온라인 트렌젝션, 웹 서비스를 위해 최적화된 플랫폼을 제공함으로써 데이타 센터의 공간문제, 전력문제, 냉방문제를 획기적으로 개선하였습니다. 썬의 멀티쓰레딩 기술(CMT)를 사용하여 썬 파이어 T2000 서버는 고레벨의 계산 집적도와 가격 대 성능비를 제공 합니다. 더 자세한 정보는 sun.com 을 참고 하시기 바랍니다.

썬 파이어 T2000 서버는 한개의 울트라SPARC T1 CPU에 4, 6 혹은 8개의 코어 옵션을 가지고 있습니다(16, 24 혹은 32 쓰레드) 그리고 32G바이트 이상의 메모리를 지원 합니다.(참고: 64G 이상을 지원할 계획이 있음) 고레벨의 네트워크 트레픽 그리고 혹은 대용량의 데이타셋을 이용하는 어플리케이션의 울트라SPARC T1 프로세서의 타겟이므로 썬 파이어 T2000 서버는 10/100/1000 Mbit/초의 4가지 이더넷 아답터, 3가지 PCI-E 슬롯 그리고 두개의 PCI-X 슬롯을 지원합니다. 이러한 기능들의 조합은 온라인 트렌젝션 프로세싱(OLTP) 이 필요로한 고성능의 네트워크 트레픽 처리 기능 혹은 DSS 워크로드를 위한 고용량의 저장용량 필요성을 훌륭하게 지원하도록 합니다.

스토리지 중심의 설정을 통해 썬 파이어 T2000 서버는 선택적으로 듀얼 채널 4-Gbit FC PCI-E 호스트 어댑터를 지원함으로써 약 20Gbit/sec의 I/O 대역폭을 제공할 수 있습니다. 일반적으로 잘 튜닝된 I/O 중심의 어플리케이션 시스템 조합은 이론적으로 I/O 대역폭의 약 80퍼센트까지 활용할 수 있습니다. 이러한 경우에 썬 파이어 T2000 서버에서는 사용가능한 I/O 대역폭에서1.6Gbytes/sec 정도의 속도를 의미 합니다. 내부 테스트에서는 1.8 Gbytes/sec 의 I/O 대역폭을 달성했습니다. 비슷하게 2-Gbit/sec HBA 를 이용해 썬 파이어 T2000 서버는 약 800 Mbytes/sec 의 I/O 대역폭을 달성했습니다.

네트워크중심 적인 어플리케이션에서 4개의 Gbit 이더넷 어답터는 모든 썬 파이어 T2000 서버의 설정에서 사용이 가능합니다. 일반적으로 4개의 어답터의 조합은 더이상의 네트워크 어답터를 필요로하지 않습니다. 어쨌든 썬은 추가적으로 10-Gbit 이더넷 133-MHz PCI-X 카드가 사용이 가능하도록 하였습니다.

솔라리스10은 144개 이상의 프로세스 유닛을 지원할 수 있음이 입증되었고 DTrace, 솔라리스 존, 그리고 자원 풀 같은 기능을 통해 관리자가 빠르게 솔라리스 플랫폼을 어플리케이션의 워크로드에 맞도록 설정 할 수 있습니다. 솔라리스10은 스케쥴러 최적화를 활용하여 코어를 기반으로 가상 CPU 상에 쓰레드를 스케쥴 할 수 있도록 해 줍니다. 그러므로 어떤 특정한 코어에 부하가 걸리는 것을 막아 줍니다. 자원 풀을 이용하여 솔라리스10은 관리자가 어플리케이션의 사용량을 조정할 수 있도록 해주고 각자에 맞게 자원을 할당해 줄 수 있으며 또한 다른 어플리케이션에 영향을 미치는 어플리케이션을 고립화 시킴으로써 시스템을 최적화 할 수 있도록 해 줍니다. 존은 운영환경을 솔라리스10 커널을 이용해 각각의 루트 패스워드를 가지는 운영환경으로 가상화 함으로써 여러개의 독립적인 존을 만들 수 있도록 해 줍니다. 이것은 각각의 다른 관리자가 다른 어플리케이션에 영향을 받지 않고 그들의 어플리케이션을 조종할 수 있도록 도와 줍니다. 자원 풀과 솔라리스 존을 통해서 솔라리스 컨테이너라고 알려진 안전한 운영환경을 제공합니다. 퍼포먼스나 디버깅 이슈들을 위해 DTrace는 사용자가 이미 개발이 완료된 환경에서도 문제의 원인을 찾을 수 있도록 도와 줍니다.

DB2 유니버설 데이타베이스 (UDB) 는 데이타베이스 관리 시스템으로써 견고한 온-디멘드 비지니스 어플리케이션을 구축하기 위한 유연하고 비용절감적인 데이타 베이스 플랫 폼입니다. DB2 UDB는 오픈 표준들에 대한 광범위한 지원 뿐만 아니라 J2EE나 마이크로스프트 .NET 같은 환경도 지원함으로써 각 리소스들을 혼합 할 수 있도록 해 줍니다. DB2 UDB 계열은 또한 비지니스 인텔리전트나 향상된 툴링 같은 특정한 분야에 맞춰진 솔루션들도 포함하고 있습니다 더 자세한 정보는 IBM 웹 사이트 를 참고 바랍니다.

DB2 UDB 는 다양한 방법을 통해 SMP 방식의 기계에서 확장될 수 있습니다. 그리고 CMT 기반의 울트라SPARC T1은 SMP의 요구조건을 만족합니다. 모든 DB2 컨넥션은 DB2 컨넥션을 서비스 하기 위해 생성되는 새로운 에이젼트 프로세스를 통해서 확장 됩니다. DB2 컨넥션은 복잡한 계산을 요구합니다. 그리고 DB2 는 INTRA_PARALLEL 옵션을 통해 병렬화의 정도(DFT_DEGREE) 에 따라 여러개의 에이젼트 프로세스를 생성하고 일을 이러한 에이젼트에게 분담시킴으로써 확장될 수 있습니다. 선택사항인 동적 파티셔닝 기능은 또한 DB2가 데이타베이스를 파티셔닝 키 혹은 파티셔닝 테이블의 그룹에 따라 두개 혹은 그 이상의 가상 데이타셋으로 분리할 수 있도록 하고 시스템에 사용 가능한 프로세싱 유닛의 수 만큼 확장될 수 있도록 합니다.

그러므로 이러한 다양한 기술들의 조합으로 DB2는 시스템 내의 자원들을 효과적으로 활용할 수 있도록 해 줍니다.

이 섹션은 T1 프로세서상에서 운용되고 있는 솔라리스10에 DB2의 배치를 최적화 하는 방법을 알아보는 섹션입니다.

2006년 6월 부터 모든 썬 파이어 T2000 서버는 솔라리스10과 같이 출시됩니다. 배포되는 솔라리스는 118822-25 버젼의 커널 패치가 되어 있습니다. DB2에서 최적의 성능을 얻기 위해서는 가장 최신의 커널 패치인 118822-30 과 118833-03 을 설치하여 페이지 문제를 수정하시기 바랍니다. 또한 패치 120849-04 을 설치하여 ipge 드라이버를 v1.32 로 최적화 하시기 바랍니다. (솔라리스10 6/06 으로 업그레이드 시에는 이러한 패치들과 함께 ZFS라 불리는 새로운 기능도 포함됩니다.)

# modinfo |grep ipge
103 7ba6c000  43650  56   1  ipge (IPGE Ethernet Driver v1.32)

다음의 예제는 썬파이어 T2000 서버에서 운영되는 솔라리스10에 DB2가 최적으로 사용되기 위한 /etc/system 의 튜닝가능 예제입니다.

튜닝은 기본적으로 네트워크 어답터, 고성능의 공유 메모리, DB2가 많은 수의 컨넥션을 가지기 위해 필요로 한 세마포어 설정등이 포함됩니다. (정보: DB2에 포함된 db2osconf 유틸리티를 사용해 보시기 바랍니다.)

* Recommended Network settings for DB2/SunFire T2000
set sq_max_size=100
set ip:ip_squeue_bind=0
set ip:ip_squeue_fanout=1
set ipge:ipge_tx_syncq=0
set ipge:ipge_taskq_disable=0
set ipge:ipge_bcopy_thresh=512
set ipge:ipge_dvma_thresh=1
* For systems shipped before June 2006 enable
* set pcie:pcie_aer_ce_mask=0x1

* From db2osconf
set msgsys:msginfo_msgmni = 10240
set semsys:seminfo_semmni = 12288
set shmsys:shminfo_shmmax = 30813703372
set shmsys:shminfo_shmmni = 12288

비록db2osconf 의 출력을 통해 IPC 자원 설정값과 /etc/system 가 읽혀지고 부팅시에 커널에 의해 해석되더라도 이러한 IPC 설정값들을 prctl(1M) 혹은 projects(4) 를 통해 명시적으로 지정해 줄것을 권장 합니다. (projects(4) 와 다음 섹션의 "프로젝트 자원 설정값 튜닝" 을 참조 )

네트워크 설정값은 /etc/rc3.d/S99setndd 에 다음과 같은 내용을 추가 해서 매번 부팅시 마다 값을 설정해 줌으로써 튜닝이 가능합니다. (실행 가능한 파일의 수정을 위해 모드를 변경해야 함을 잊지 마시기 바랍니다.)

#!/bin/sh
ndd -set /dev/tcp tcp_smallest_anon_port 2048
ndd -set /dev/tcp tcp_time_wait_interval 60000
ndd -set /dev/tcp tcp_conn_req_max_q 81920
ndd -set /dev/tcp tcp_conn_req_max_q0 81920
ndd -set /dev/tcp tcp_xmit_hiwat 400000
ndd -set /dev/tcp tcp_recv_hiwat 400000
ndd -set /dev/tcp tcp_max_buf 4194304
ndd -set /dev/tcp tcp_cwnd_max 2097152

제안하는 설정값:

# projadd -U db2inst1 user.db2inst1
# projmod -a -K "project.max-shm-ids=(priv,1288,deny)" 
  user.db2inst1
# projmod -a -K "project.max-sem-ids=(priv,1288,deny)" 
  user.db2inst1
# projmod -a -K "project.max-shm-memory 
  =(priv,30813703372,deny)" user.db2inst1
# projmod -a -K "project.max-msg-ids 
  =(priv,10240,deny)" user.db2inst1

IPC 자원의 한계를 지정하는 방법으로 /etc/system 에 지정하는 대신 projects(4) 를 사용하여 재부팅시마다 값을 직접 지정하도록 권장합니다. 커맨드 projadd(4M) 는 이러한 타입의 튜닝을 /etc/project 에 추가하여 DB2 인스턴스 소유자 ID에 지정할 수 있도록 해 줍니다. (예를 들어 db2inst1).

앞에서 설명한 기본적인 설정 과정을 통해 솔라리스10은 실제로 DB2가 5000 컨넥션 이상을 사용 할 수 있도록 확장 할 수 있는 방법을 제공 합니다.

일반적인 워크로드가 아닌 특정한 워크로드를 위한 다양한 튜닝 기법이 존재하지만 이 섹션에서는 설명하지 않습니다.

FX 스케쥴러를 이용해 DB2 프로젝트를 위한 자원풀을 설정 합니다. 이 방법은 DB2를 여러개 수행해서 발생하는 인터럽트들을 분리해 줌으로써 성능을 향상 시킵니다.

이것은 poolcfg(1M) 커맨프 파일인 pool.host 을 다음과 같이 생성함으로써 수행 될 수 있습니다.

modify pset pset_default (uint pset.min=2; uint pset.max=2)
create pset db2pset  (uint pset.min=30; uint pset.max=30)
create pool db2pool (string pool.schedule="FX")
associate pool db2pool 

다음에 자원 메니저에게 명령하여 설정값을 적용 시킵니다.

# pooladm -e
# pooladm -s
# poolcfg -f pool.host
# pooladm -c
# pooladm

마지막 커맨드는 어떠한 CPU ID들이 db2pool 셋에 할당되었는지 알려 줍니다. 그 다음 psradm -i 을 사용하여 db2pool 에 CPU ID들에서 발생하는 인터럽트들이 기본 풀에 분산될 수 있도록 합니다.

만약 기본 풀에 CPU ID 29,30,31이 존재 한다면 psradm 을 이용하여 인터럽트가 다른 가상 CPU들에게 전달 되지 않도록 인터럽트를 끌 수 있습니다.

# psradm -i 0-28

그 다음 새롭게 만들어진 db2pool 을 사용하기 위해 user.db2inst1 을 적용합니다. (DB2 인스턴스의 소유자)

# projmod -a -K "project.pool=db2pool" user.db2inst1

/etc/project 는 다음과 같을 것입니다.

system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.db2inst1:100::db2inst1::project.max-msg-ids= 		
    (priv,10240,deny);project.max-sem-ids=
    (priv,1288,deny);project.max-shm-ids= 	
    (priv,1288,deny);project.max-shm-memory= 
    (priv,30813703372,deny);project.pool=db2pool

앞에서 언급된 설정대로 db2start 는 db2inst1 인스턴스 소유자 권한으로 db2pool 자원 풀 내에서 데이타베이스를 시작시킵니다(분리되지 않음) (데이타베이스를 분리하기 위해서는 Db2 정보 센터의 "자원풀을 이용해서 DB2를 설정하는 법"을 참고 바랍니다.)

DB2 환경변수 값은 썬 파이어 T2000 서버에서 DB2의 최상의 성능을 이끌어 내도록 도와 줍니다. 솔라리스상의 DB2를 위한 공통적인 값들은 일반적으로 다음과 같습니다.

db2set DB2COMM=tcpip
db2set DB2_PARALLEL_IO=*

만약 DB2의 테이블 스페이스가 UFS 파일시스템 상에서 생성되었다면 다음의 팁들은 시스템 퍼포먼스를 향상시키는데 도움이 될 것입니다.

테이블스페이스에 단편화를 피하기 위해 테이블 스페이스를 연속적으로 할당하는 AUTOMATIC STORAGE 옵션 (이것은 DB2 데이타베이스가 AUTOMATIC STORAGE 옵션이 켜진 상태로 생성될 것이 요구됨) 혹은 DATABASE MANAGED TABLESPACES 옵션을 사용합니다.

NO FILE SYSTEM CACHING 는 독자가 테이블 스페이스를 MANAGED BY DATABASE 혹은 AUTOMATIC STORAGE 옵션으로 사용시 유용할 수 있습니다. 만약 사용자가 MANAGED BY SYSTEM 옵션을 테이블 스페이스에 사용한다면 FILE SYSTEM CACHING 이 권장됩니다. DB2의 NO FILE SYSTEM CACHING 은 솔라리스에서 파일 시스템을 forcedirectio 옵션으로 마운트 하는 것과 같으며 이것은 파일 시스템 버퍼를 거치지 않고 디바이스에 직접적으로 데이타를 쓰는 방식입니다.

파일 시스템에 forcedirectio 옵션을 사용함으로써 솔라리스는 디바이스에 데이타를 쓰고 확인을 기다리는 절차를 가짐으로써 만약 디바이스가 쓰기 퍼포먼스 향상을 위해 배터리에 의해 백업된 쓰기 캐쉬를 가지고 있을때 성능상의 잇점을 얻을 수 있습니다.

DB2 와 DB 설정값은 어플리케이션 프로파일에 맞게 튜닝 되어야 합니다. 각기 다른 워크로드에 따른 권장 설정값은 다음의 섹션들에서 다루어 집니다.

OLTP 종류의 워크로드는 기본적으로 좀더 트렌젝션적으로 예를 들어 주문처리 시스템, 쇼핑 카트 어플리케이션 같은 것을 말합니다. OLTP 워크로드는 전형적으로 복잡한 처리 지향적이 아닌 흐름 지향적입니다. 이러한 타입의 워크로드의 가장 기본적인 변수는 응답시간, 초당 트렌젝션, 분당 비지니스 처리 등입니다. 이러한 것들은 일반적으로 데이타베이스에서 하나의 열 혹은 상대적으로 낮은 숫자 들의 열들을 리턴해 주는 아주 간단한 형태의 쿼리로 구분이 가능합니다. 튜닝의 설정값은 시스템의 다음과 같은 부분에 적용됩니다:

• OS와 DBMS상에서 효과적인 고성능 네트워크 컨넥션 처리와 패킷 전송 기능
• OS의 도움을 받은 DBMS의 기능으로 상대적으로 가벼운 혹은 중간 정도 수준의 SQL 쿼리들이 요청될때 효과적으로 처리하기
• 좀더 빠른 응답 시간을 가질 수 있게 하기 위한 모든 데이타의 접근 시간 향상
• 비슷한 종류의 쿼리들의 동시적인 접근을 최대한 많이 처리하기 위해 시스템이 필요한 자원들의 효과적인 튜닝

우리의 경우 기본적인 네트워크 튜닝을 적용 했고 좀 더 무거운 작업을 처리하기 위해 필요한 확장성을 위한 튜닝도 이미 적용 했습니다.

이제 이 시스템에서 DB2가 좀더 효율적인 컨넥션을 가지기 위한 방법을 알아 보겠습니다. DB2에서 효과적으로 OLTP 워크로드를 처리하기 위한 튜닝값들은 다음과 같습니다.

MAXAGENTS: 데이타베이스에 접속하는 클라이언트 어플리케이션의 수를 늘립니다.

NUM_POOLAGENT: 기본적으로 MAXAGENTS 의 반값이 대부분의 경우 적당합니다. 다만 에이젼트들의 힙들의 크기가 증가하고 있고 메모리 제약시 심할때에는 예외입니다. 이러한 경우 NUM_POOLAGENT 값을 감소 시켜야 하며 이것은 새로운 컨넥션을 맺을때 에이젼트 프로세스 생성이 요구되는 단점을 가지고 있습니다.

NUM_INITAGENT: 일반적으로 솔라리스에서는 0 혹은 데이타베이스 컨넥션의 최소 숫자와 일치 시킵니다.

다음의 DB 설정값들이 기본 값에서 튜닝을 필요로한 것들의 목록입니다.

db2 update dbm cfg using SHEAPTHRES         20000
db2 update dbm cfg using MAXAGENTS          5000
db2 update dbm cfg using DFT_MON_LOCK       OFF
db2 update dbm cfg using DFT_MON_UOW        OFF
db2 update dbm cfg using rqrioblk           16384
db2 update dbm cfg using JAVA_HEAP_SZ       128
db2 update dbm cfg using ASLHEAPSZ          256
db2 update dbm cfg using QUERY_HEAP_SZ      2048

MAXAPPLS: 일반적으로 MAXAGENTS 보다 작거나 같게 설정합니다. 그렇지 않으면 DB2는 컨넥션 집중자를 사용할 것입니다.

다음의 DB 설정값들이 기본 값에서 튜닝을 필요로한 것들의 목록입니다.(주의: 요구되는 정확한 값은 실행되고 있는 어플리케이션의 종류에 따라 달라집니다.)

db2 update db cfg for dbname using MAXAPPLS 5000
db2 update db cfg for dbname using locklist 65535
db2 update db cfg for dbname using logbufsz 512
db2 update db cfg for dbname using seqdetect NO
db2 update db cfg for dbname using logfilsiz 65535
db2 update db cfg for dbname using logprimary 3
db2 update db cfg for dbname using num_ioservers 2
db2 update db cfg for dbname using num_iocleaners 2
db2 update db cfg for dbname using MAXLOCKS 100

다른 DBM 과 DB 설정값은 각 에이젼트 프로세스들이 좀더 효과적으로 빈번한 컨넥션 요구에 대처할 수 있도록 튜닝될 수 있습니다. 그러므로 설정 값들은 데이타베이스를 위해 계획된 SQL 구분의 종류와 데이타베이스의 목적에 따라 매우 달라 집니다. (OLTP 워크로드는 일반적으로 데이타베이스 상에서 어플리케이션들이 사용할 것으로 기대되는 잘 알려진 SQL 구문의 셋을 가지고 있습니다.)

데이타베이스의 컨넥션수가 과다하여 물리 램의 부족현상이 발생한다면 다음의 값들을 좀 더 낮게 잡음으로써 에이젼트가 좀더 적은 메모리를 소비하고 RAM을 해제하여 좀 더 많은 에이젼트가 생성될 수 있도록 해 줍니다.

db2 update db cfg for dbname using sortheap 64
db2 update db cfg for dbname using STMTHEAP 256
db2 update db cfg for dbname using APPLHEAPSZ 128
db2 update db cfg for dbname using APPGROUP_MEM_SZ 128
db2 update db cfg for dbname using SHEAPTHRES_SHR 250
db2 update db cfg for dbname using UTIL_HEAP_SZ 64
db2 update db cfg for dbname using STAT_HEAP_SZ 1096

DSS 워크로드는 일반적으로 매우 복잡하고 계산 적인 쿼리들을 가지고 있습니다. 이러한 워크로드는 장시간 동안 수행되는 쿼리로 특성되어 집니다. 워크로드의 DSS 종류를 측정하기 위해 사용되는 변수는 시간당 처리량, 시간당 쿼리량, 시간당 자료 처리량 등입니다. 일반적으로 DSS 쿼리의 목적은 클라이언트 어플리케이션의 수백개의 요청을 처리하는 것이 아니라 단 하나의 쿼리를 매우 빠르게 처리 하기 위한 것입니다. DSS의 쿼리는 하나 혹은 몇개의 열을 리턴해주는 OLTP와는 다르게 여러개의 열을 리턴해 줍니다. 그러므로 DSS의 튜닝은 OLTP와 틀립니다.

DSS 종류의 쿼리의 성능을 좀 더 향상시키기 위해 솔라리스를 약간 튜닝 할 수도 있습니다.

예를 들어 /etc/system 은 시스템과 스토리지 시스템 간에 I/O 작업이 가능한 대역폭을 향상 시킬 수 있도록 더 큰 I/O 사이즈의 작업을 가능하게 해주는 튜닝 할 수 있습니다.

set maxphys=1048576
set md:md_maxphys=1048576

두번째 옵션은 솔라리스 볼륨 메니저에서 사용됩니다; 이 옵션은 metainit(1M) 에 의해 정의된 볼륨들을 사용하지 않는 다면 소용 없습니다.

만약 DB2 테이블 스페이스에 FILE SYSTEM CACHING 옵션을 사용한다면 다음과 같은 방법이 퍼포먼스 향상에 도움을 줄 수 있습니다.

set ufs:ufs_WRITES=0
set ufs:freebehind=0
set segmap_percent=40

UFS가 좀 더 큰 I/O 사이즈를 사용하도록 하기 위해 파일 시스템은 다음과 같이 튜닝될 필요가 있습니다.

tunefs -a 128 /data/db2

좀 더 큰 I/O 크기를 사용하여 DSS 종류의 워크로드의 처리를 돕기 위해 다음과 같은 작업을 할 수 있습니다:

• 테이블 스페이스에 좀 더 큰 페이지 크기를 할당 함 (DB2의 기본 크기는 4K 이고 8K 혹은 32K 증가시킬 수 있음)
• 테이블의 extentsize 값을 pagesize * extents 가 /etc/system 에 지정된 maxphys 와 동일하도록 설정.

DB2 INTRA_PARALLEL 옵션은 DSS 종류의 쿼리들의 퍼포먼스 향상을 위한 빠른 선택입니다. 솔라리스의 prstat 툴을 -am 을 주고 실행시켜서 INTRA_PARALLEL 옵션을 실행시키는 것이 도움이 될지 안될지를 판단해야 합니다. 만약 prstat 의 출력이 하나 혹은 그 이상의 db2sysc 프로세스가 평균 시스템 CPU(iostat혹은 vmstat에서 볼 수 있는) 활용율이 낮은 상태에서 유저 + 시스템의 합이 거의 100%에 가깝다면, DB2 INTRA_PARALLEL 옵션은 썬 파이어 T2000에서 도움이 됨을 의미 합니다.

기본적으로 ANY 로 설정된 기본 수준의 병렬화 (DFT_DEGREE) 를 사용합니다. 기본적으로 (DB2 파티션의 수 x 병렬화의 수준) 정도의 값을 사용하되 이 값이 독립 DB2 유저의 퍼포먼스를 위한 CPU 쓰레드의 갯수를 넘지 않도록 합니다. 싱글 파티션된 DB2의 경우는 다음의 식을 이용하면 DFT_DEGREE 는 32가 될 것입니다. 그러나 이러한 시나리오에서 DFT_DEGREE 3 과 8 사이에서 테이블 스페이스의 접근 패턴에 따라 디스크의 병목현상이 일어날 것입니다. 그러므로 DFT_DEGREE 값을 이것이 넘지 않도록 설정합니다.

만약 많은 수의 DSS 사용자들이 존재 한다면 높은 값의 DFT_DEGREE 는 시스템에 더 많은 로드를 줄 것입니다. 그러므로 가장 좋은 방법은 DFT_DEGREE 를 4 로 지정하고 CPU의 활용도와 어플리케이션 워크로드의 퍼포먼스에 따라 값을 조정하는 것이 가장 좋습니다.

db2 update dbm cfg using INTRA_PARALLEL     ON
db2 update db cfg for dbname using DFT_DEGREE 4

DSS 종류의 쿼리의 퍼포먼스를 향상시키는 다른 방법으로는 선택적인 확장의 새로운 철학을 가지고 있는 DB2 DPF 기능을 이용하여 데이타베이스를 분할 할 수 있습니다. 썬 파이어 T2000 서버에서 적정한 파티션의 갯수는 "코어의 갯수"와 같습니다. INTRA_PARALLEL 옵션과 DFT_DEGREE 을 4로 설정하여 시스템에서 좀더 성능향상을 이끌어 낼 수 있습니다.

DB2 파티션은 프로젝트가 사용 가능합니다. 각 DB2 파티션의 자원들은 db2nodes.cfg 에 프로젝트를 지정함으로써 조종이 가능합니다. 프로젝트는 자원풀에 할당 될 수 있고 그러므로 각 파티션을 효율적인 퍼포먼스와 최소의 마이그레이션을 위한 고유의 자원 풀을 할당하여 고립 시킬 수 있습니다.

이러한 설정의 예는 DB2 Information Center 에서 찾아보실 수 있습니다.

이 글에서 언급된 설정, 튜닝의 팁들은 시스템 관리자와 DB2 DBA들이 IBM DB2를 썬 파이어 T2000 서버의 솔라리스10 상에서 최적의 퍼포먼스를 가질 수 있도록 빠르게 설정할 수 있는 방법을 제공했습니다.

• Developing and Tuning Applications on UltraSPARC T1 Chip Multithreading Systems (pdf)
• Sun Fire T2000 Server - Sun Systems Handbook
• Sun Update Connection - Patches and Updates
• IBM's DB2 Information Center
• The DB2 UDB Memory Model
• Everything You Wanted to Know About DB2 Universal Database Processes

Jignesh Shah 은 썬의 마켓 개발 엔지니어링팀에서 ISV 파트너들을 도와 제품을을 썬의 환경에 통합하는데 도움을 주는 역활을 하고 있습니다. 블로그는 weblog 에서 확인 하실 수 있습니다.