18.4. 리소스 소비

데이터베이스 서버가 공유 메모리 버퍼용으로 사용하는 메모리 양을 설정한다. 기본값은 일반적으로 128메가바이트(128MB)이지만 커널 설정에서 지원하지 않는 경우 여기에 미치지 못할 수 있다(initdb 중에 결정됨). 이 설정은 최소 128킬로바이트여야 한다. (기본값이 아닌 BLCKSZ 값은 최소값을 변경한다.) 단, 최소값보다 훨씬 큰 설정은 일반적으로 우수한 성능이 필요할 때 사용된다.

RAM이 1GB 이상인 전용 데이터베이스 서버를 사용하는 경우 shared_buffers의 적절한 시작 값은 시스템 메모리의 25%이다. 일부 작업 부하는 shared_buffers에 대한 설정이 클수록 효과적이지만, PostgreSQL 역시 운영 체제 캐시에 의존적이므로 시스템 효율을 위해 40% 이상의 RAM을 shared_buffers에 할당하는 것은 좋지 않다. 장시간에 걸쳐 대량의 새 데이터 또는 변경된 데이터 쓰기 프로세스를 실행하기 위해 shared_buffers를 더 크게 설정하면 checkpoint_segments에서도 그에 맞게 설정을 증가시켜야 한다.

시스템 RAM이 1GB 미만인 경우에는 운영 체제를 위한 적정 공간이 필요하므로 RAM 비율을 더 작게 하는 것이 맞다. 또한 Windows에서 shared_buffers 값을 크게 하는 것은 효과적이지 않다. 설정을 작게 하고, 운영 체제는 캐시는 상대적으로 크게 함으로써 더 나은 결과가 나올 수도 있다. Windows 시스템의 shared_buffers에 대한 유용한 범위는 64MB ~ 512MB이다.

거대(huge) 메모리 페이지를 활성/비활성으로 설정한다. 유효 값은 try(기본값), on 및 off이다.

현재 이 기능은 Linux에서만 지원된다. try로 설정되면 다른 시스템에서 설정이 무시된다.

huge pages 페이지의 사용은 결과적으로 메모리 관리에 더 작은 페이지 테이블과 더 짧은 CPU 시간으로 이어지고 성능도 증가한다. 자세한 내용은 17.4.4절을 참조 바란다.

huge_pages를 try로 설정하면 서버가 huge pages의 사용을 시도하지만, 실패 시 일반적인 할당을 사용하는 쪽으로 폴백한다. on의 경우 huge pages의 사용에 실패하면 서버가 시작되지 않는다. off의 경우 huge pages를 사용하지 않는다.

각 데이터베이스 세션이 사용하는 임시 버퍼의 최대 수를 설정한다. 임시 테이블에 액세스하는 용도로만 사용되는 세션 로컬 버퍼가 있다. 기본값은 8메가바이트(8MB)이다. 설정은 개별 세션 내에서 변경할 수 있지만 세션 내 임시 테이블을 처음 사용하기 전에만 가능하다. 이후에 값을 변경하면 해당 세션에서 효과가 없다.

세션은 temp_buffers에 설정된 한계까지, 필요한 임시 버퍼를 할당한다. 실제로는 임시 버퍼가 많이 필요 없는 세션에서 큰 값을 설정하는 데 드는 비용은 버퍼 디스크립터 또는 temp_buffers 증가별로 약 64바이트에 불과하다. 그러나 버퍼가 실제로 사용되는 경우에는 8192바이트가 추가로 필요하다(또는 일반적으로 BLCKSZ 바이트).

동시에 "준비된" 상태일 수 있는 트랜잭션의 최대 수를 설정한다(PREPARE TRANSACTION 참조).

준비된 트랜잭션을 사용할 계획이 없으면 이 매개변수는 0으로 설정하여 준비된 트랜잭션을 생성하는 실수를 방지해야 한다. 준비된 트랜잭션을 사용하는 경우 max_prepared_transactions가 최소한 max_connections 이상이 되도록 설정하여 세션은 준비된 트랜잭션을 보류시킬 수 있다.

대기 서버 실행 중에 이 매개변수를 마스터 서버 값보다 크거나 같게 설정해야 한다. 그렇지 않으면 대기 서버에서 쿼리가 허용되지 않는다.

임시 디스크 파일을 쓰기 전에 내부 정렬 명령 및 해시 테이블에서 사용되는 메모리 양을 지정한다. 기본값은 4메가바이트이다(4MB). 복잡한 쿼리의 경우 몇 가지 정렬 또는 해시 명령이 병렬로 실행될 수 있다. 각각의 명령은 데이터를 임시 파일에 쓰기 전에 이 값에 지정된 크기만큼 메모리를 사용할 수 있다. 또는 실행 중인 몇 개의 세션은 해당 명령을 동시에 실행할 수도 있다. 따라서 사용된 총 메모리는 work_mem의 배수가 될 수 있다. 값을 선택할 때 이러한 사실을 유념할 필요가 있다. 정렬 명령은 ORDER BY, DISTINCT 및 머지 조인에 사용된다. 해시 테이블은 해시 조인, 해시 기반 집계(aggregation), IN 서브쿼리의 해시 기반 처리에 사용된다.

VACUUM, CREATE INDEX 및 ALTER TABLE ADD FOREIGN KEY 같은 유지보수 명령에서 사용되는 최대 메모리 양을 지정한다. 기본값은 64메가바이트이다(64MB). 이러한 명령은 데이터베이스 세션에서 한 번에 하나만 실행할 수 있으며, 정상 설치에는 동시 실행되는 명령이 여러 개 있을 수 없다. 이 값은 work_mem보다 훨씬 큰 값으로 설정하는 것이 안전하다. 설정값이 큰 경우에는 vacuuming 및 데이터베이스 덤프 복구 성능이 개선될 수 있다.

autovacuum 실행 시 이 메모리에서 autovacuum_max_workers의 배수로 할당할 수 있으므로 기본값을 너무 높게 설정하지 않도록 해야 한다. autovacuum_work_mem을 별도 설정하여 이것을 관리하는 것이 유용할 수 있다.

각각의 autovacuum worker 프로세스에서 사용되는 최대 메모리 양을 지정한다. 기본값은 maintenance_work_mem 값을 대신 사용해야 함으로 나타내는 -1이다. 다른 컨텍스트에서 실행하는 경우 이 설정은 VACUUM의 동작에 효과가 없다.

서버 실행 스택의 최대 안전 깊이를 지정한다. 이 매개변수의 이상적인 설정은 커널이 강제로 지정한 안전 마진(safety margin)에서 약간 부족한 실제 스택 크기 제한이다(ulimit -s에 의해 설정된 대로, 또는 로컬과 동등). 표현식 평가(expression evaluation) 같이 서버의 모든 루틴이 아니라 잠재적 재귀 루틴 중 중요한 것만 스택 깊이가 검사되기 때문에, 안전 마진(safety margin)이 필요하다. 기본 설정은, 기본적으로 적게 잡고 충돌 가능성이 낮은 2메가바이트이다(2MB). 그러나, 설정값이 너무 작으면 복합 함수의 실행이 어려울 수 있다. 수퍼유저만 이 설정을 변경할 수 있다.

실제 커널 제한보다 max_stack_depth를 큰 값으로 설정하면 런어웨이 재귀 함수가 개별 백엔드 프로세스와 충돌할 수 있다. PostgreSQL이 커널 제한을 결정할 수 있는 플랫폼에서 서버는 이 변수가 불안정한 값으로 설정되는 것을 허용하지 않는다. 그러나 모든 플랫폼이 정보를 제공하지는 않으므로 값 선택 시 신중을 기해야 한다.

서버가 사용해야 하는 동적 공유 메모리 구현을 지정한다. 가능한 값은 posix(shm_open을 사용하여 할당된 POSIX 공유 메모리의 경우), sysv(shmget을 통해 할당된 System V 공유 메모리의 경우), windows(Windows 공유 메모리의 경우), mmap(데이터 디렉토리에 저장된 메모리 맵 파일을 사용하는 공유 메모리 시뮬레이션) 및 none(이 기능 비활성)이다. 몇몇 플랫폼에서는 일부 값이 지원되지 않는다. 첫 번째 지원 옵션은 해당 플랫폼의 기본값이다. 플랫폼에서 기본값이 아닌 mmap 옵션의 사용은 일반적으로 권장되지 않는다. 이유는 운영 체제가 수정된 페이지를 디스크에 반복해서 다시 쓰면서 시스템 I/O 로드가 늘어나기 때문이다. 그러나, pg_dynshmem 디렉토리를 RAM 디스크에 저장하거나 다른 공유 메모리 기능을 사용할 수 없는 경우에는 디버깅용으로 유용하다.

정렬 및 해시 임시 파일 같은 임시 파일 또는 보류된 커서용 저장소 파일에 세션이 사용할 수 있는 디스크 공간의 최대 크기를 지정한다. 이 제한을 초과하는 트랜잭션은 취소된다. 값은 킬로바이트 단위로 지정되며 -1(기본값)은 무제한을 의미한다. 수퍼유저만 이 설정을 변경할 수 있다.

이 설정은 주어진 PostgreSQL세션에 의해 동시에 사용되는 모든 임시 파일의 총 공간을 제한한다. 쿼리 실행 시 은밀하게 사용되는 임시 파일과 달리, 명시적 임시 테이블용으로 사용되는 디스크 공간은 이 제한에 합산되지 않는다는 점에 유의해야 한다.

서버 하위 프로세스별로 허용된 동시 개방 파일의 최대 수를 설정한다. 기본값은 1000개 파일이다. 커널이 프로세스별 안전 한계를 강제하는 경우 이 설정은 신경 쓸 필요가 없다. 그러나 일부 플랫폼(특히, 대부분의 BSD 시스템)에서, 여러 개의 프로세스가 모두 다수의 파일을 열려고 시도하면 커널은 시스템이 실제로 지원하는 것보다 훨씬 더 많은 파일을 개별 프로세스가 여는 것을 허용한다. "Too many open files" 실패가 나타난 경우 이 설정을 줄여야 한다. 이 매개변수는 서버 시작 시에만 설정 가능하다.

비용 제한을 초과한 경우 프로세스가 슬립하는 초 단위의 시간 길이. 기본값은, 비용 기반 vacuum 지연 기능을 사용하지 않는 0이다. 양의 값은 비용 기반 vacuuming을 사용하는 것으로 설정된다. 다수의 시스템에서 슬립 지연의 효율적인 설정은 10밀리초이다. vacuum_cost_delay를 10의 배수가 아닌 다른 값으로 설정하면 10의 배수로 값을 올림하여 설정한 것과 결과가 동일하다.

비용 기반 vacuuming을 사용하는 경우 vacuum_cost_delay는 일반적으로 매우 작으며, 보통 10 ~ 20밀리초이다. vacuum의 자원 소비를 조절하려면 다른 vacuum 비용 매개변수를 변경하는 것이 가장 좋다.

공유 버퍼 캐시에 있는 버퍼 vacuuming의 예상 비용. 이것은 버퍼 풀을 잠그고, 공유 해시 테이블을 조회하고 페이지 내용을 스캔 하는 비용을 나타낸다. 기본값은 1이다.

디스크에서 읽어온 버퍼를 vacuuming하는 데 드는 예상 비용. 이것은 버퍼 풀을 잠그고, 공유 해시 테이블을 조회하고, 디스크에어 원하는 블록을 읽고, 내용을 스캔하는 비용을 나타낸다. 기본값은 10이다.

이전에 클린한 블록을 vacuum이 수정하는 경우 예상 비용. 이것은 dirty 블록을 디스크에 다시 쓰는 데 필요한 추가 I/O를 나타낸다. 기본값은 20이다.

vacuuming 프로세스를 슬립 시키는 누적 비용. 기본값은 200이다.

백그라운드 writer의 작업 라운드 사이의 지연을 지정한다. 각 라운드에서 writer는 몇 개의 dirty 버퍼(다음 매개변수로 조절 가능)에 대해 쓰기를 실행한다. 그런 다음, bgwriter_delay 밀리초 동안 슬립한 다음, 반복한다. 버퍼 풀에 dirty 버퍼가 없으면, bgwriter_delay와 무관하게 장기 슬립으로 들어간다. 기본값은 200밀리초이다(200ms). 다수의 시스템에서 슬립 지연의 효율적인 설정은 10밀리초이다. bgwriter_delay를 10의 배수가 아닌 다른 값으로 설정하면 10의 배수로 값을 올림하여 설정한 것과 결과가 동일하다. 이 매개변수는 postgresql.conf 파일 또는 서버 커맨드 라인에서만 설정 가능하다.

각 라운드에서 이것보다 큰 버퍼 수는 백그라운드 writer에 의해 쓰기가 되지 않는다. 이것을 0으로 설정하면 백그라운드 쓰기가 사용되지 않는다. (별도의 전용 보조 프로세스에 의해 관리되는 해당 checkpoints는 영향을 받지 않는다.) 기본값은 100개 버퍼이다. 이 매개변수는 postgresql.conf 파일 또는 서버 커맨드 라인에서만 설정 가능하다.

각 라운드에 쓰기 된 dirty 버퍼의 수는 최근 라운드 중에 서버 프로세스가 필요로 했던 새 버퍼 수를 근거로 한다. 최근의 평균 요구량은 다음 라운드에서 필요한 버퍼 추정치에 도달하도록 bgwriter_lru_multiplier를 곱한다. 깨끗하고 재사용 가능한 버퍼 수가 지정된 개수가 될 때까지 dirty 버퍼는 쓰여진다. (그렇더라도 라운드당 bgwriter_lru_maxpages 이상의 버퍼는 쓰여지지 않는다.) 따라서, 1.0 설정은 정확히 필요한 버퍼 수를 기록하는 "just in time" 정책을 나타낸다. 더 큰 값을 설정하면 수요 급증에 대비할 수 있는 반면, 더 작은 값은 쓰기를 서버 프로세스가 처리하도록 일부러 미처리 상태로 방치한다. 기본값은 2.0이다. 이 매개변수는 postgresql.conf 파일 또는 서버 커맨드 라인에서만 설정 가능하다.

PostgreSQL가 동시에 실행 가능할 것으로 예상하는 동시 디스크 I/O 실행 수를 설정한다. 이 값을 올리면 각 PostgreSQL 세션이 병렬 초기화를 시도하는 I/O 실행 수가 늘어난다. 허용 범위는 1 ~ 1000, 또는 비동기 I/O 요청의 실행을 비활성화하는 0이다. 현재, 이 설정은 비트맵 힙 스캔에만 영향을 미친다.

이 설정을 위한 권장 시작점은 데이터베이스에서 사용되는 RAID 0 스트라이프 또는 RAID 1 미러를 환경 설정하는 개별 드라이브 수이다. (RAID 5의 경우 패리티 드라이브 수는 계산하지 않는다. ) 그러나 동시 세션에서 여러 개의 쿼리가 실행된 상태에서 데이터베이스가 매우 바쁠 경우, 디스크 배열을 busy 상태로 유지하기 위해서는 적은 값도 충분하다. 디스크를 busy한 상태로 만들기 위해 필요 이상으로 큰 값을 설정하면 CPU 오버헤드만 가중된다.

버스 대역폭에 의해 제한되는 메모리 기반 저장소 또는 RAID 배열 같은 외부 시스템의 경우, 가용한 I/O 경로 수를 설정해야 한다. 최상의 값을 찾아내려면 몇 가지 시험이 필요할 수도 있다.

비동기 I/O는 효과적인 posix_fadvise 함수에 따라 달라지며, 이것이 운영 체제에 없을 수도 있다. 이 함수가 없을 경우 이 매개변수를 0 이외의 다른 것으로 설정하면 에러가 발생한다. 일부 운영 체제(예: Solaris)에는 함수가 존재하지만 실제로는 아무것도 하지 않는다.

시스템이 지원할 수 있는 백그라운드 프로세스의 최대 수를 설정한다. 이 매개변수는 서버 시작 시에만 설정 가능하다.

대기 서버 실행 중에는 이 매개변수를 마스터 서버 값보다 크거나 같게 설정해야 한다. 그렇지 않으면 대기 서버에서 쿼리가 허용되지 않는다.