ONCONFIG 매개변수 ROOTSIZE: rootdbs size Logical Logs + [Phys logs] + [Temp Tables] + [Data] + [On-Arc.catalogs] 이것은 기본적인 크기 계산 공식입니다. 중요한 시스템의 경우 이러한 각각의 논리적 단위는 대부분 개별적인 dbspace에 둘 수 있습니다. SERVERNUM: CPU 상의 각 데이터베이스 엔진마다 고유한 값을 가짐 RESIDENT 전용 서버에서는 이 값을 1로 세팅하십시오. 혼합 응용 프로그램 환경에서는 이것으로 인해 Informix가 예상보다 훨씬 많은 자원을 소비해 버릴 수도 있습니다. NUMCPUVPS : CPU VP 갯수 HW CPU(HW CPU)가 세 개 이상일 경우에는 NUMCPUVPS를 CPU 수보다 하나 적게 설정합니다. 데이터 로딩을 위해서는 이것을 HW CPU 수와 동일하게 설정합니다. HPL을 사용하는 경우에는 이것을 HW CPU - CONVERTVPS(onpload 매개변수) 수와 동일하게 설정합니다. 필자는 VCPUS 대 HW CPU를 1:1로 설정하는 시스템과 2:1로 설정하는 시스템을 모두 본 적이 있습니다. HW CPU 수가 4 이하라면 NUMCPUVPS를 1 또는 2로 설정할 것을 권장합니다. 하지만 일반적으로는 이런 중요한 매개변수에 대해 꼭 그렇게 해야 한다는 불변의 법칙을 찾지 못했기 때문에 각각의 시스템에 맞게 경험적으로 시행하는 것이 바람직할 것입니다. MULTIPROCESSOR와 SINGLECPU 이 둘은 서로 다른 관리 규정 메커니즘에 따라 작동합니다. 만일 NUMCPUVPS가 1로 설정되어 있다면 이 둘을 모두 OFF로 설정(각각 0과 1)해야 합니다. 이 둘이 모두 OFF 상태가 아니라면 단일 CPUVP 구성이 갖는 이점을 얻지 못할 것입니다. 이 점이 종종 간과되고 있습니다! 이 둘은 실제로 하나의 매개변수로서 취급해야 합니다. 하나를 조정하면 다른 하나도 마찬가지로 조정해야 합니다. NOAGE 이것은 1로 설정하십시오. 이 매개변수가 지원되는 경우 UNIX 나이싱(nicing)이 OFF 상태가 됩니다 (이것이 바람직합니다). 나이싱은 혼합 환경에서 동등성을 보장할 수 있도록 시간에 따라 처리의 우선 순위를 낮춰 주는 UNIX 메커니즘입니다. 전용 서버에서는 NOAGE를 활성화해야 합니다. 혼합 환경에서는 이렇게 분명한 튜닝 방법이 없습니다. 초기에는 이 값을 OFF 상태로 두고, 이후에 Informix에 CPU 시간을 보다 많이 할당하고자 하는 경우에 ON으로 전환하는 것이 최상의 방법일 것입니다. AFF_SPROC : 바인드를 시작하는 CPU 숫자 AFF_NPROCS : 바인드할 하드웨어 CPU 수 NUMCPUVPS = HW CPU - AFF_SPROC 이것은 전용 데이터베이스 서버가 아닌 경우에 유용합니다. Informix 이외의 작업들은 여기서 지정한 HW CPU 상에서 처리할 수 있지만, CPUVPS는 여기에서 지정한 HW CPU로만 제한될 것입니다. USEOSTIME: 0: 내부적 시간 사용(fast) (초까지 지원), 1: OS으로 부터 시간을 가져옴(slow) (소수점 3째자리 초까지 지원) BUFFERS (페이지): 버퍼의 갯수 핵심적인 OLTP 튜닝 필드 20% RAM부터 50% RAM까지도 가능(전용 서버인 경우 50%로 시작해도 무방함) 캐시율(cache hit ratio)의 증가가 미비하거나, 과도한 시스템 페이징이 발생할 때까지 이 값을 높입니다. 페이징의 과도 여부를 결정하려면 sar 또는 vmstat 명령을 사용합니다. OLTP 환경의 목표는 읽기 캐시율 95%와 쓰기 캐시율 85%입니다. 데이터 로딩을 위해서는 최대화 합니다(50% 이상)(HPL 익스프레스 모드 제외). 버퍼가 더 많다는 것은 체크포인트가 더 길다는 것을 의미할 수 있습니다. NUMAIOVPS - 이 매개변수에 대한 권장 사항은 상황에 따라 가변적임 데이터베이스 디스크 당 1, 그리고 접근 빈도가 높은 각 청크마다 1씩 추가 KAIO가 사용되는 경우 기본 1, 각각의 가공된 청크에 대해 2씩 추가(모든 가공된 청크 제거) KAIO 시스템의 경우 OnLine 엔진에 대해 2, 그리고 가공된 청크를 포함하는 컨트롤러 당 1씩 추가하여 설정 KAIO가 없는 시스템의 경우 OnLine 엔진에 대해 2, 각 컨트롤러에 대해 1로 설정한 이후 지시 사항대로 추가 DB영역 당 1 디스크 당 1 미러된 쌍(mirrored pair) 당 1 청크 당 1 DSA(Informix Dynamic Scalable Architecture™)는 DB영역(AIO나 KAIO) 당 하나의 읽기 스레드를 산출한다는 점에 유의하시기 바랍니다. onstat -g ioq 명령을 사용하여 입출력 큐를 감시하고 필요한 만큼 추가하십시오. KAIO를 지원하는 시스템을 장만한 후에 NUMAIOVPS를 2로 설정할 것을 권장합니다. RA_PAGES: 4 page 대부분의 컴퓨터는 미리 읽을(read ahead) 페이지 수를 30으로 제한합니다(모든 컴퓨터에서 32로 제한할 것입니다). 가벼운 스캔(light scans)을 수행하는 시스템에서는 RA_PAGES를 32 이상으로 설정하지 마십시오. 이것을 너무 높게 설정하면 읽기 캐시 비율(%cache reads)이 낮아집니다. bufwaits 가 비정상적으로 높다면 RA_PAGES가 지나치게 높게 설정되었거나 RA_PAGES와 RA_THRESHOLD 사이의 차이가 너무 작기 때문일 것입니다. 전형적인 순차 DSS 데이터베이스에 대해서는 더 높게 설정하십시오. RA_THRESHOLD: 2 page DBSPACETEMP 최소한 두 개를 구성하는데, 각각 서로 다른 축(spindle)에서 하십시오. 큰 색인을 구축하고자 한다면 더 많이 구성하십시오. DSS 환경에서는 여러 디스크에 걸쳐 몇몇 TEMPDBS로 하드웨어 스트라이핑(hardware stripe)을 해야 합니다. FILLFACTOR (색인) 일반적으로 90, DELETE 또는 SELECT 작업이 주로 수행되는 테이블에 대해서는 100 이것은 초기에 매우 간결한 색인과 효율적인 캐시를 갖게 함 노드 분할(node splitting)의 요구를 지연시키기 위해 높은 INSERTS를 갖는 테이블에는 50-70% MIRROR 항상 미러링을 하는 것이 좋습니다. 수 년 전에 Informix에서 미러링 테스트를 했던 사람이 매번 Informix 미러링 대신 하드웨어 미러링을 사용하라는 자신의 견해를 말한 바 있습니다. 이 주장에는 일리가 있습니다. 하드웨어 레벨에서 제공하는 솔루션은 소프트웨어보다 빠를 수 있습니다. 하드웨어, OS, 그 다음 Informix 미러링으로 우선 순위를 정할 것을 제안합니다. 유용성이 뛰어난 컴퓨터의 경우 컨트롤러와 어레이까지도 미러링을 할 수 있습니다. TBLSPACE_STATS 1로 설정할 경우, 잘 알려지지 않은 이 매개변수는 onstat -g ppf로 볼 수 있는 테이블영역(tblspace) 프로파일 통계치를 생성할 것입니다. 오버헤드를 줄이려면, 측정을 하지 않을 때 이것을 OFF 상태(0)로 두십시오. CLEANERS: Number of buffer cleaner processes 디스크 수 20 미만의 경우 디스크 당 1 디스크 수 20-100의 경우 2개 디스크 당 2 디스크 수 100 초과의 경우 디스크 당 4 LRU 큐 한 쌍 당 최소 하나로 구성(필자의 경우 이 비율이 근래 최상으로 작동함) onstat -F를 통해 모든 cleaners가 활성 상태임을 확인하게 되면 더 많이 할당하십시오. PHYSDBS:physical log가 들어있는 dbspace PHYSFILE: physical log size = 사용자 스레드 * 5 (또는 가장 빈번한 BLOB의 크기) * 4 PHYSBUFF: physical log buffer size LOGFILES: logical log file 갯수 > 3 LOGSIZE: 하나의 logical log size > 200kb LOGBUFF: RAM 내 3개의 논리 로그 버퍼의 크기 디스크에 대한 플러싱의 빈도를 결정함 LOGSMAX: 허용하는 최대 logical log 파일의 갯수 LOGFILES + 3 CKPTINTVL 이는 체크포인트의 간격을 조정합니다. LRU를 참고하십시오. 데이터 로딩(HPL 익스프레스 모드 제외)과 병렬 색인 구축을 위해 3000으로 설정 간격이 길면 물리 로그 크기에서 체크포인트의 발생 시점(즉, 수행된 작업량)을 결정할 수 있음 onstat -F는 쓰기가 LRU 방식인지 CHKPTINTVL 방식인지 보여줌 LRUS: LRU 큐 갯수 onstat -R로 볼수 있음 LRU_MAX[MIN]_DIRTY - 수정된 큐에 할당된 %buffers 체크포인트 지속 시간을 줄일 수 있도록 이를 낮게 설정할 것. 데이터 로딩(HPL 익스프레스 모드 제외)과 병렬 색인 구축을 하려는 경우, 플러싱 전에 거의 다 차려면 70%와 80%가 허용될 것입니다. CLEANER 스레드에 의해 이 매개변수가 수행하는 onstat -R 큐 길이와 -F 쓰기를 감시하십시오. LTAPEDEV /dev/null에 설정하면, Informix는 논리 로그를 백업된 것으로 표시하기만 하고 더 이상 작업을 진행하지 않을 것입니다. 이렇게 하면 훨씬 더 빠릅니다. 이는 논리 로그 복구가 필요하지 않은 시스템에 대해서만 실행해야 하며 사용자가 이를 잘 숙지하고 있어야 합니다. LTXHWM 50 LTXEHWM 60 NETTYPE tlitcp,1,30,NET CPU가 1이면 추가적인 폴 스레드를 NETVPs에 할당 단일 HW CPU에는 300, 그 이상이면 350 데이터 로딩을 위해서는 CPUVP 당 하나. 각각의 폴 스레드가 CPU class VPS 상에 있어야 함(인라인으로 폴 스레드 운영) 이것으로 인해 폴 스레드를 위한 작업이 증가할 것이므로 사용자 접속을 늘리지 마십시오. LOCKS: LOCK의 최대갯수 SHMVIRTSIZE (킬로바이트) Decision Support Systems(DSS)를 위한 핵심적인 튜닝 매개변수 페이징이 유발되지 않는 경우 DSS를 75% RAM으로 증가 가능 OLTP 환경에서는 상주(버퍼)는 크게, 가상(SHMVIRTSIZE)은 작게 만드십시오. DSS 환경의 경우는 그 반대입니다. SHMADD (킬로바이트) SHMVIRTSIZE의 10-20%. SHMTOTAL 무제한으로 하려면 0으로 설정 onstat -g seg를 사용하여 현재 사용중인 메모리 세그먼트를 확인할 수 있습니다. onmode -F(사용되지 않는 메모리 세그먼트를 free시킴) MAX_PDQPRIORITY 100 DUMPSHMEM 0으로 지정하십시오. Informix의 shared memory dump로 인해 /tmp가 full이 되어 장애를 일으키는 시스템이 많이 있습니다. 초기값을 OFF로 해야 합니다. LBU_PRESERVE 0 # Preserve last log for log backup ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT OPTCOMPIND 2 # To hint the optimizer DATASKIP # List of dbspaces to skip