| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 17. 서버의 설정 | Fast Forward | Next |
데이터 베이스 서버가 사용하는 공유 메모리 버퍼를 위해서 사용하는 메모리량을 설정합니다. 디폴트는 전형적으로는 32 메가바이트(32MB)입니다만, 사용하는 커넬의 설정이(initdb의 과정에서) 거기까지를 지원하지 않으면 보다 적게 설정되는 경우가 있습니다. 최저한의 설정은 128킬로바이트가 되어야 하고, 그리고 16킬로바이트 배 max_connections이상이 아니면 안됩니다. (디폴트 이외의BLCKSZ에서는 이 최소값은 바뀝니다. ) 그러나, 좋은 성능을 위해서는, 최소값보다 훨씬 높은 설정이 통상 필요합니다. 제품 설치에서는 수십 메가바이트 정도의 값을 추천 합니다. 이 매개변수는 서버 기동시만 설정 가능합니다.
이 매개변수를 증가시키면,PostgreSQL는 사용하고 있는 운영 시스템의 디폴트 설정이 허용 하는System V공유 메모리의 한계를 넘은 요구를 실시하는 요인이 되는 경우가 있습니다. 필요하면, 이 매개변수를 조정하는 방법에 관하여Section 16.4.1를 참조해 주십시오.
각각의 데이터베이스 세션이 사용하는 임시 버퍼의 최대수를 설정합니다. 이것들은 임시 테이블에 액세스 할 때에게만 사용되는 세션 로컬 버퍼입니다. 디폴트는 8 메가바이트(8MB)입니다. 설정은 각각의 세션내에서 변경할 수 있습니다만, 세션내의 임시 테이블이 최초로 사용하기까지만 변경 가능합니다. 계속해서 값의 변경을 시도해도, 그 세션에서는 효과가 없습니다.
세션은temp_buffers로 주어진 한도까지, 필요로 하는 임시 버퍼를 할당합니다. 실제로는 많은 임시 버퍼를 필요로 하지 않는 세션에, 큰 값을 설정하는 대상은temp_buffers에서의 증가마다, 버퍼 기술자용 , 혹은 약 64바이트입니다. 그러나, 버퍼가 실제로 사용되면, 그에 대한 추가의 8192바이트(혹은, 통상BLCKSZ바이트)가 소비됩니다
동시에"준비된"상태에 있어서의 트랜잭션(transaction)의 최대수를 설정합니다. ( PREPARE TRANSACTION 를 참조해 주세요. ) 이 매개변수를 제로로 설정하면, 준비된 트랜잭션(transaction) 기능을 무효로 합니다. 디폴트는 5 트랜잭션(transaction)입니다. 이 매개변수는 서버 기동시에만 설정 가능합니다.
준비된 트랜잭션(transaction)를 사용하지 않는 경우, 이 매개변수도 이와 같이 제로로 설정됩니다. 사용하는 경우, 준비 단계에서의 쓸데없는 지장을 회피하기 위해 max_prepared_transactions를 적어도max_connections같은 크기로 해도 상관하지 않습니다.
이 매개변수를 증가시키면, 사용하고 있는 운영 시스템의 디폴트 설정이 허용 하는System V공유 메모리의 한계를 넘은 요구를 PostgreSQL가 실시하는 요인이 되는 경우가 있습니다. 필요하면, 이 매개변수를 조정하는 방법에 관해서 Section 16.4.1를 참조해 주십시오.
임시 디스크 파일의 변환전에, 내부의 정렬조작 및 해시 테이블 조작이 사용하는 메모리 용량을 지정합니다. 디폴트값은 1 메가바이트(1MB)입니다. 복잡한 쿼리의 경우, 몇 개의 정렬 혹은 해시조작이 병행하여 실행되는 것에 주의해 주세요. 각각은, 데이터를 임시 파일에 두기 전에, 이 값이 지정한 것과 같은 크기의 메모리 사용이 인정됩니다. 게다가 몇 개의 실행중의 세션은 이러한 동작을 동시에 실시합니다. 따라서, 사용되는 메모리의 합계는,work_mem의 수 배가 됩니다. 값을 선택할 때에는, 이 사실에 유의할 필요가 있습니다. 정렬조작은ORDER BY,DISTINCT, 및 병합조인에 대해서 사용됩니다. 해시 테이블은 해시 결합, 해시에 근거한 집약, 및IN쿼리의 해시에 근거한 처리로 사용됩니다.
VACUUM,CREATE INDEX, 및ALTER TABLE ADD FOREIGN KEY의 같은 운영 조작으로 사용되는 메모리의 최대 용량을 지정합니다. 디폴트치는 16 메가바이트(16MB)입니다. 1개의 데이터베이스 세션에서는, 한 번에 1개 밖에 상기의 조작을 할 수 없습니다. 그리고, 통상 설치로 이러한 조작이 동시에 많이 발생할 일은 없기 때문에, 이것을work_mem보다 훨씬 많은 값으로 지정해도 안전합니다. 큰 값을 설정하는 것으로 vacuum 처리와 데이터베이스 덤프의 복구 성능이 향상합니다.
서버의 실행 스택의 최대 안전 깊이를 지정합니다. 이 매개변수의 이상적인 설정은 커넬에 의해 강요받는 실제의 스택 용량의(ulimit -s혹은 로컬에서의 동등의 값으로 설정된) 한계로부터, 1 메가바이트 정도의 안전 여지를 공제한 것입니다. 안전 여지는, 스택 깊이는 서버가 각 루틴으로 검사를 하지 않고, 수식 평가등이 주요한 잠재적으로 재귀적인 루틴의 경우 때문에만, 필요한 것입니다. 디폴트 설정은 2 메가바이트(2MB)로, 꽤 조심스러워, 크래쉬의 위험은 없을 것 같습니다. 그러나, 복잡한 함수의 실행을 허용 하기에는 너무 작을지도 모릅니다. 슈퍼 유저만이 이 설정을 변경할 수 있습니다.
max_stack_depth를 실제의 커넬의 제한보다 더 큰 값으로 설정했을 경우, 이탈한 재귀 함수에 의해, 개개의 백엔드 프로세스가 크래쉬 할지도 모릅니다. PostgreSQL에 의해 커넬의 제한을 결정할 수 있는 플랫폼으로도, 이 변수를 위험한 값으로 설정하지 않습니다. 그러나, 모든 플랫폼이 이 정보를 제공할 수 있는 것은 아닙니다. 이 때문에, 값을 선택할 때에는 주의가 필요합니다.
이러한 매개변수는, 데이터베이스의 미사용 영역의 장소를 추적해, 공유빈영역 맵(FSM)의 크기를 관리합니다. 맵에 기재가 없는 빈영역은 재사용되지 않기 때문에, 통상보다 작게 여겨진 빈영역은, 시간의 경과에 따라 데이터베이스가 증가하는 디스크 영역 용량을 소비하는 원인이 됩니다. 대신에, PostgreSQL는, 신규 데이터의 저장이 필요하게 되었을 경우, 운영 시스템에 큰 디스크 영역을 요구합니다. 데이터베이스VACUUM VERBOSE커멘드가 표시하는 마지막 몇 줄은, 현재의 설정이 적절하지 않을 때 도움이 됩니다. 현재의 설정이 현저하고 작은 경우,NOTICE메세지는, 이 조작의 실행중과 같이 표시됩니다.
이러한 매개변수를 증가시키면, 사용하고 있는 운영 시스템의 디폴트 설정이 허용 하는System V공유 메모리의 한계를 넘은 요구를 PostgreSQL가 실시하는 원인이 되는 경우가 있습니다. 필요하면, 이 매개변수를 조정하는 방법에 대해서Section 16.4.1를 참조해 주십시오.
빈영역이 공유 빈영역 맵내에서로 추적되는 디스크 페이지의 최대수를 설정합니다. 6바이트의 공유 메모리가 각각의 페이지 슬롯에서 소비됩니다. 이 설정은 적어도, 16 * max_fsm_relations보다 크지 않으면 안됩니다. 디폴트는 이용 가능한 메모리량에 응해initdb가 결정되어, 20 k에서 200 k의 값이 됩니다. 이 매개변수는 서버 기동시만 설정 가능합니다.
빈영역이 공유 빈영역 맵내에서 추적되는 릴레이션(테이블과 인덱스)의 최대수를 설정합니다. 대체로, 70바이트의 공유 메모리가 각각의 슬롯에 대해서 소비됩니다. 디폴트는 1000 릴레이션입니다. 이 매개변수는 서버 기동시만 설정 가능합니다.
각각의 서버 서브프로세스를 동시에 오픈할 수 있는 파일수의 최대치를 설정 합니다. 디폴트는 1000 파일입니다. 커넬이 프로세스 마다의 안전 제한을 강요하고 있는 경우, 이 설정을 걱정할 필요는 없습니다. 그러나, 몇개의 플랫폼(특히 대부분의 BSD 시스템)에서는, 매우 많은 프로세스 모두가 많은 파일을 열려고 했을 때에, 커넬은 개개의 프로세스가 시스템을 실제로 지원할 수 있는 파일수보다 많은 파일을 여는 것을 허락하고 있습니다. 만약"Too many open files"에러가 발생했을 경우, 이 설정을 감소해 보세요. 이 매개변수는 서버 기동시만 설정 가능합니다.
이 변수는 서버가 가동하는 시점에서 사전에 로드되는 1개 혹은 그 이상의 공유 라이브러리를 지정합니다. 복수의 라이브러리를 로드하는 경우는, 라이브러리명을 콤마로 분리해 주세요. 예를 들어,'$libdir/mylib'는mylib.so(일부의 플랫폼에서는mylib.sl)를 설치의 표준 라이브러리 디렉토리로부터 사전에 로드됩니다. 이 매개변수는 서버 기동시에게만 설정 가능합니다.
PostgreSQL의 절차 언어 라이브러리는 이와 같은 식으로, 전형적으로는 구문'$libdir/plXXX'를 사용하여, 사전에 로드됩니다. 여기서,XXX는pgsql,perl,tcl, 혹은python입니다.
공유 라이브러리를 사전에 로드하여, 라이브러리가 최초로 사용될 때, 라이브러리의 개시 시간을 생략 할 수 있습니다. 그러나, 각각의 신규 서버 프로세스를 개시시키는 시간은, 그 프로세스가 라이브러리를 사용하지 않는다고 해도, 다소 증가하는 일이 있습니다. 그러므로, 이 매개변수는 대부분의 세션으로 사용될 것 같은 라이브러리에게만 한정하는 것을 추천합니다.
Note: Windows에서는, 서버 기동시에 라이브러리를 사전에 로딩해도, 새로운 서버 프로세스의 기동에 필요로 하는 시간은 줄어들지 않습니다. 각 서버 프로세스는 사전에 읽힌 라이브러리를 모두, 다시 로드합니다. 그러나,shared_preload_libraries는 Windows 호스트라도 유용합니다. 공유 라이브러리안에는, postmaster 기동시에게만 특정의 조작을 실시할 필요가 있을 수 있기 때문입니다. (예를 들면, 공유 라이브러리는, postmaster의 기동이 끝난 후에 실행할 수가 없는, 가벼운 락이나 공유 메모리의 예약을 실시할 필요가 있을 수 있습니다. )
지정한 라이브러리가 존재하지 않으면 서버의 기동에 실패합니다.
PostgreSQL가 지원하는 라이브러리는 모두, 호환성을 보증하기 위해서 검사되는"매직 블록"을 가집니다. 이 때문에, 이 방법으로 PostgresQL 이외의 라이브러리가 로드될 수 없습니다.
VACUUM 및 ANALYZE 커멘드의 실행중, 실행되는 각종 I/O조작의 예측 코스트를 계속 추적하는 내부 가산기를 시스템이 유지보수합니다. 누적된 코스트가(vacuum_cost_limit로 지정된) 한도에 이르면, 조작을 실행하고 있는 프로세스는(vacuum_cost_delay로 지정된) 잠시동안 정지합니다. 그 후, 가산기를 재설정하여, 실행을 계속합니다.
이 기능의 목적은, 동시적 데이터베이스 활동에 대한 이러한 커멘드의 I/O에 대한 영향을 관리자로부터 경감시킵니다. VACUUM 및 ANALYZE의 같은 보수용 커멘드가, 빠르게 종료하는 것에 대해 중요하지 않은 정황이 많이 있습니다. 그러나, 이러한 커멘드가 다른 데이터베이스의 조작을 실시하는 시스템의 능력에 저해를 주지 않는 것은 매우 중요합니다. 코스트에 근거한 vacuum 지연은 이것을 실현하기 위한 방법을 관리자에게 제공합니다.
디폴트로 이 기능은 무효로 되어 있습다. 유효하게 하려면 ,vacuum_cost_delay변수를 제로가 아닌 값으로 설정합니다.
코스트의 한도를 초과 했을 경우, 프로세스가 정지(sleep)하는 밀리 세컨드 단위의 시간의 길이입니다. 디폴트의 값은 0으로, 코스트에 근거한 vacuum 지연 기능을 무효로 합니다. 정의 정수는 코스트에 근거한 vacuum를 유효하게 합니다. 많은 시스템으로, 정지 지연의 유효한 분해가능은 10 밀리 세컨드입니다. vacuum_cost_delay의 값의 설정을 10의 배수로 하지 않는 경우, 다음에 큰 10의 배수로 설정한 결과와 동일하게 될 수도 있음을 기억하세요.
공유 버퍼 캐시안의 버퍼에 vacuum를 거는 예측 코스트입니다. 버퍼 풀의 락, 공유 해시 테이블의 검색, 및 페이지 내용 주사의 코스트를 나타냅니다. 디폴트의 값은 1입니다.
디스크로로부터 읽혀야 하는 버퍼에 vacuum을 거는 예측 코스트입니다. 이것이 가리키는 것은, 버퍼 풀 락의 시도, 공유 해시 테이블의 검색, 디스크로부터 목적 블록의 읽어들여, 그리고 그 내용을 스캔합니다. 디폴트의 값은 10입니다.
vacuum이, 전에 삭제한 블록을 변경할 때에 완수된 예측 코스트입니다. 더티 블록을 다시 디스크에 플러시하는데 필요한 여분의 I/O를 나타냅니다. 디폴트의 값은 20입니다.
vacuum을 거는 프로세스를 정지시키는 누계 된 코스트입니다. 디폴트의 값은 200입니다.
Note: 중요한 락을 보유해 가능한 한 시급하게 완료해야 하는 어떤 종류의 조작이 있습니다. 코스트에 근거한 vacuum 지연은 이와 같은 조작에서는 일어나지 않습니다. 따라서, 코스트의 누계가 지정된 한도를 훨씬 넘을 가능성이 있습니다. 이러한 경우 쓸데없는 긴 지연을 방지하기 위해, 실제의 지연은 이하와 같이 계산됩니다. vacuum_cost_delay * accumulated_balance / vacuum_cost_delay * 4 의 최대치를 소유한다 vacuum_cost_limit
PostgreSQL 8.0의 시작에, 백그라운드 라이터로 불리는 분리된 서버 프로세스가 있어, 그 기능은"더티"공유 버퍼의 기입 처리를 실시하는 것입니다. 그 목적은, 유저의 쿼리에 대응하고 있는 서버 프로세스는 발생하는 기입을, 백그라운드 라이터가 맡고 있기 때문에, 대기 상태가 되지 않게 하는 것입니다. 이러한 배합은 또한 체크포인트와 연관된 성능 패널티를 감소시킵니다. 백그라운드 라이터는, 각각의 체크포인트에서 전에 발생한 더티 버퍼의 연쇄 대신에, 계속적으로 더티 페이지를 디스크로 옮깁니다. 따라서 체크포인트 시각이 도달할시에는 몇몇의 페이지들만 강요되도록 합니다. 그러나, 반복적으로 변경되는 페이지에서는, 이것이 없으면 체크포인트 간격 당 한 번만 기술될 가능성이 있었습니다만, 백그라운드 라이터는 같은 간격내에서 여러 차례 기술되기 때문에, 전체적으로의 I/O부하는 많아집니다. 대부분의 상황에서 주기적인 스파이크보다 계속되는 낮은 로드가 더 바람직하지만, 본절에서 설명한 이 매개변수는 로컬의 독자적인 필요에 따라서 동작을 변경하는 것에 사용할 수 있습니다.
백그라운드 라이터의 동작 주기간의 지연을 지정합니다. 각각의 주기에 라이터는, (이하의 매개변수로 관리된다) 일부의 더티 버퍼의 기입을 실시합니다. 그리고bgwriter_delay밀리 세컨드동안 정지한 후, 이것을 반복 합니다. 디폴트의 값은 200 밀리 세컨드(200ms)입니다. 많은 시스템에서 효과적인 정지 지연의 정도는 10 밀리 세컨드입니다. bgwriter_delay의 값의 설정을 10의 배수로 하지 않는 경우, 다음에 더 큰 10의 배수로 설정한 결과와 동일하게 될 수도 있다는 것을 기억하세요. 이 매개변수는postgresql.conf파일내, 또는, 서버의 커멘드 라인으로 설정 가능합니다.
서버 프로세스가, 그들이 작성한 것을 발행하는 확률을 감소하려면, 백그라운드 라이터가 곧 리사이클 될 것 같은 버퍼를 작성해야 합니다. 각 주기에서, 리사이클된 된것과 가장 가까운 버퍼의 bgwriter_lru_percent까지 검사합니다. 그리고 더티가 있는 모든 것을 작성합니다. 디폴트값은 1.0(총 공유된 버퍼의 수의 1%)입니다. 이 매개변수는 서버 커멘드 라인상에서 또는 postgresql.conf파일 내에서만 설정됩니다.
각각의 주기로, 이 수이상의 버퍼는 백그라운드 라이터에 의해 기입되지 않습니다. 디폴트값은 5 버퍼입니다. 이 매개변수는postgresql.conf파일내, 또는, 서버의 커멘드 라인에서만 설정 가능합니다.
체크포인트 시간에 필요로 하는 작업량을 감소하기 위해서, 백그라운드 라이터는 더티가 발견되는 버퍼를 기입하는 전체 버퍼풀을 통하여 순환주사(스캔)을 실행합니다. 각 주기에서, 이러한 목적을 위해 버퍼의 bgwriter_all_percent까지 검사합니다. 디폴트 값은 0.333 (총 공유된 버퍼수의 0.333%)입니다. 디폴트로 bgwriter_delay를 설정하고, 1분에 한번씩 전체의 공유 버퍼풀에 스캔되는 것을 허용합니다. 이 매개변수는postgresql.conf파일내, 또는, 서버의 커멘드 라인에서만 설정 가능합니다.
각각의 주기에서, 이 수 이상의 버퍼는 전체 버퍼풀의 결과로서 기입되지 않습니다. (이것이 한도에 도달하는 경우, 스캔은 정지하고, 다음 주기 동안에 다음의 버퍼에서 재개됩니다.) 디폴트값은 5 버퍼입니다. 이 매개변수는postgresql.conf파일내, 또는, 서버의 커멘드 라인에서만 설정 가능합니다.
bgwriter_all_percent및bgwriter_all_maxpages 의 값이 보다 작으면 백그라운드 라이터에 의해 발생되는 추가의 I/O부하를 감소시키지만, 서버 프로세스가 자기 자신이 실행해야 하는 기입이 증가하게 되어, 상호적인 쿼리를 지연하게 됩니다. 이와 같게, bgwriter_lru_percent및bgwriter_lru_maxpages 의 값이 보다 작으면 백그라운드 라이터에 의해 발생되는 추가의 I/O부하를 감소시키지만, 서버 프로세스가 자기 자신이 실행해야 하는 기입이 증가하게 되어, 상호적인 쿼리를 지연하게 됩니다. 백그라운드 작성을 완전히 불가능하게 하려면, maxpages의 값 둘다 및/또는 percent의 값 양쪽 모두를 0으로 설정합니다.