다음을 통해 공유

리소스 사용량/메모리

autovacuum_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 각 자동 진공 작업자 프로세스에서 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 -1
허용되는 값 -1-2097151
매개 변수 형식 dynamic
문서 autovacuum_work_mem

커밋 타임스탬프 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 커밋 타임스탬프 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다. 이 값을 shared_buffers 분수로 결정하려면 0을 지정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 0-131072
매개 변수 형식 정적
문서 커밋 타임스탬프 버퍼

동적_공유_메모리_타입

특성 가치
카테고리 리소스 사용량/메모리
Description 사용되는 동적 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 posix
허용되는 값 posix
매개 변수 형식 읽기 전용
문서 동적_공유_메모리_타입

해시 메모리 곱셈기 (hash_mem_multiplier)

특성 가치
카테고리 리소스 사용량/메모리
Description 해시 테이블에 사용할 "work_mem"의 배수입니다.
데이터 형식 numeric
기본값 2
허용되는 값 1-1000
매개 변수 형식 dynamic
문서 hash_mem_multiplier

huge_pages

특성 가치
카테고리 리소스 사용량/메모리
Description Linux 또는 Windows에서 거대한 페이지 사용
데이터 형식 enumeration
기본값 try
허용되는 값 on,off,try
매개 변수 형식 정적
문서 huge_pages

Description

거대한 페이지는 더 큰 블록에서 메모리를 관리할 수 있는 기능입니다. 일반적으로 표준 4KB 페이지와 달리 최대 2MB의 블록을 관리할 수 있습니다.

거대한 페이지를 사용하면 CPU를 효과적으로 오프로드하는 성능 이점을 제공할 수 있습니다.

  • TLB(변환 색인 버퍼) 누락이 줄어드는 등 메모리 관리 작업과 관련된 오버헤드가 감소합니다.
  • 메모리 관리에 필요한 시간을 단축합니다.

특히 PostgreSQL에서는 공유 메모리 영역에 대해서만 거대한 페이지를 사용할 수 있습니다. 공유 메모리 영역의 상당 부분이 공유 버퍼에 할당됩니다.

또 다른 장점은 거대한 페이지가 공유 메모리 영역을 디스크로 교환하지 못하게 하여 성능을 더욱 안정화한다는 것입니다.

Recommendations

  • 메모리 리소스가 많은 서버의 경우 거대한 페이지를 사용하지 않도록 설정하지 마십시오. 거대한 페이지를 사용하지 않도록 설정하면 성능이 저하됩니다.
  • 대규모 페이지를 지원하지 않는 더 작은 서버로 시작하지만, 대규모 페이지를 지원하는 서버로 업그레이드할 계획이 있는 경우, 원활한 전환과 최적의 성능을 위해 huge_pages 설정을 TRY로 유지합니다.

Azure 관련 메모

vCore가 4개 이상인 서버의 경우 기본 운영 체제에서 거대한 페이지가 자동으로 할당됩니다. vCore가 4개 미만인 서버에서는 이 기능을 사용할 수 없습니다. 공유 메모리 설정이 변경되거나 shared_buffers과 같은 세부 사항이 변경되면 대용량 페이지 수가 자동으로 조정됩니다.

huge_page_size (큰 페이지 크기)

특성 가치
카테고리 리소스 사용량/메모리
Description 요청해야 하는 거대한 페이지의 크기입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 huge_page_size

io_combine_limit

특성 가치
카테고리 리소스 사용량/메모리
Description 데이터 읽기 및 쓰기 크기에 제한이 있습니다.
데이터 형식 integer
기본값 16
허용되는 값 1-128
매개 변수 형식 dynamic
문서 io_combine_limit

io_max_combine_limit

특성 가치
카테고리 리소스 사용량/메모리
Description io_combine_limit을 제한하는 서버 전체 제한입니다.
데이터 형식 integer
기본값 16
허용되는 값 1-128
매개 변수 형식 dynamic
문서 io_max_combine_limit

io_max_concurrency

특성 가치
카테고리 리소스 사용량/메모리
Description 한 프로세스가 동시에 실행할 수 있는 최대 IO 수입니다.
데이터 형식 integer
기본값 64
허용되는 값 -1-1024
매개 변수 형식 정적
문서 io_max_concurrency

I/O 메서드

특성 가치
카테고리 리소스 사용량/메모리
Description 비동기 I/O를 실행하는 메서드를 선택합니다.
데이터 형식 enumeration
기본값 worker
허용되는 값 worker,sync
매개 변수 형식 정적
문서 io_method

io_workers

특성 가치
카테고리 리소스 사용량/메모리
Description io_method=worker의 IO 작업자 프로세스 수입니다.
데이터 형식 integer
기본값 3
허용되는 값 1-32
매개 변수 형식 dynamic
문서 io_workers

logical_decoding_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 논리 디코딩에 사용할 최대 메모리를 설정합니다. 각 내부 재정렬 버퍼는 디스크로 넘기기 전에 이 정도의 메모리를 사용할 수 있습니다.
데이터 형식 integer
기본값 65536
허용되는 값 64-2147483647
매개 변수 형식 dynamic
문서 logical_decoding_work_mem

maintenance_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 유지 관리 작업에 사용할 최대 메모리를 설정합니다. 여기에는 VACUUM 및 CREATE INDEX와 같은 작업이 포함됩니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 1024-2097151
매개 변수 형식 dynamic
문서 maintenance_work_mem

Description

maintenance_work_mem 는 PostgreSQL의 구성 매개 변수입니다. 유지 관리 작업에 할당된 메모리 양(예: VACUUM, CREATE INDEX및 ALTER TABLE)을 제어합니다. 쿼리 작업에 대한 메모리 할당에 영향을 주는 것과 달리 work_mem데이터베이스 구조를 유지 관리하고 최적화하는 작업을 위해 예약되어 있습니다 maintenance_work_mem .

! [참고] 지나치게 공격적인 값으로 설정 maintenance_work_mem 하면 시스템에서 메모리 부족 오류가 주기적으로 발생할 수 있습니다. 이 매개 변수를 변경하기 전에 서버에서 사용할 수 있는 메모리 양과 앞에서 설명한 작업에 메모리를 할당할 수 있는 동시 작업 수를 이해하는 것이 매우 중요합니다.

핵심 사항

  • 진공 메모리 한도: maintenance_work_mem를 늘려 데드 튜플의 정리 속도를 높이고자 한다면, VACUUM에 데드 튜플 식별자를 수집하는 데 기본적으로 제한이 내재되어 있다는 점을 유의하세요. 이 프로세스에는 최대 1GB의 메모리만 사용할 수 있습니다.
  • 자동 진공을 위한 메모리 분리: 자동 진공 작업에서 독립적으로 사용하는 메모리를 제어하는 설정을 사용할 autovacuum_work_mem 수 있습니다. 이 설정은 .의 하위 집합으로 작동합니다 maintenance_work_mem. 다른 유지 관리 작업 및 데이터 정의 작업에 대한 메모리 할당에 영향을 주지 않고 자동 진공에서 사용하는 메모리 양을 결정할 수 있습니다.

Azure 관련 메모

maintenance_work_mem 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 maintenance_work_mem 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 maintenance_work_mem 값에 따라 매개 변수 값도 조정해야 합니다.

maintenance_work_mem 값을 계산하는 데 사용되는 수식은 (long)(82.5 * ln(memoryGiB) + 40) * 1024입니다.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 maintenance_work_mem
2GiB 99,328 KiB
4GiB 157,696KiB
8GiB 216,064KiB
16GiB 274,432 KiB
32GiB 332,800KiB
48GiB 367,616 KiB
64GiB 392,192KiB
80GiB 410,624KiB
128GiB 450,560KiB
160GiB 468,992 KiB
192GiB 484,352 KiB
256GiB 508,928 KiB
384GiB 542,720 KiB
432GiB 552,960KiB
672GiB 590,848 KiB

max_prepared_transactions

특성 가치
카테고리 리소스 사용량/메모리
Description 동시에 준비된 최대 트랜잭션 수를 설정합니다.
데이터 형식 integer
기본값 0
허용되는 값 0-262143
매개 변수 형식 정적
문서 max_prepared_transactions

max_stack_depth

특성 가치
카테고리 리소스 사용량/메모리
Description 최대 스택 깊이(킬로바이트)를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 2048
매개 변수 형식 읽기 전용
문서 max_stack_depth

min_dynamic_shared_memory

특성 가치
카테고리 리소스 사용량/메모리
Description 시작 시 예약된 동적 공유 메모리 양입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 min_dynamic_shared_memory

multixact_member_buffers

특성 가치
카테고리 리소스 사용량/메모리
Description MultiXact 멤버 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다.
데이터 형식 integer
기본값 32
허용되는 값 16-131072
매개 변수 형식 정적
문서 multixact_member_buffers

멀티트랜잭트_오프셋_버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description MultiXact 오프셋 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다.
데이터 형식 integer
기본값 16
허용되는 값 16-131072
매개 변수 형식 정적
문서 multixact_offset_buffers (멀티엑스액트 오프셋 버퍼)

알림_버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description LISTEN/NOTIFY 메시지 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다.
데이터 형식 integer
기본값 16
허용되는 값 16-131072
매개 변수 형식 정적
문서 notify_buffers

직렬화 가능 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 직렬화 가능한 트랜잭션 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다.
데이터 형식 integer
기본값 32
허용되는 값 16-131072
매개 변수 형식 정적
문서 serializable_buffers

공유 버퍼 (shared_buffers)

특성 가치
카테고리 리소스 사용량/메모리
Description 서버에서 사용하는 공유 메모리 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 16-1073741823
매개 변수 형식 정적
문서 shared_buffers

Description

구성 매개 변수는 shared_buffers 데이터를 버퍼링하기 위해 PostgreSQL 데이터베이스에 할당된 시스템 메모리 양을 결정합니다. 모든 데이터베이스 프로세스에서 액세스할 수 있는 중앙 집중식 메모리 풀 역할을 합니다.

데이터가 필요한 경우 데이터베이스 프로세스는 먼저 공유 버퍼를 확인합니다. 필요한 데이터가 있는 경우 빠르게 검색되고 시간이 많이 걸리는 디스크 읽기를 무시합니다. 공유 버퍼는 데이터베이스 프로세스와 디스크 간의 중개자 역할을 하며 필요한 I/O 작업의 수를 효과적으로 줄입니다.

Azure 관련 메모

shared_buffers 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 서버 매개 변수에 대한 기본값에 shared_buffers 영향을 주지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 shared_buffers 값에 따라 매개 변수 값도 조정해야 합니다.

최대 2GiB의 메모리가 있는 가상 머신의 경우 값을 shared_buffers 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 16384.

2GiB를 초과하는 가상 머신의 shared_buffers 경우 값을 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 32768.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 공유 버퍼 (shared_buffers)
2GiB 32768
4GiB 131072
8GiB 262144
16GiB 524288
32GiB 1048576
48GiB 1572864
64GiB 2097152
80GiB 2621440
128GiB 4194304
160GiB 5242880
192GiB 6291456
256GiB 8388608
384GiB 12582912
432GiB 14155776
672GiB 22020096

공유_메모리_유형

특성 가치
카테고리 리소스 사용량/메모리
Description 기본 공유 메모리 영역에 사용되는 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 mmap
허용되는 값 mmap
매개 변수 형식 읽기 전용
문서 공유_메모리_타입

subtransaction_buffers

특성 가치
카테고리 리소스 사용량/메모리
Description 하위 변환 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다. 이 값을 shared_buffers 분수로 결정하려면 0을 지정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 0-131072
매개 변수 형식 정적
문서 subtransaction_buffers

임시 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 각 세션에서 사용되는 최대 임시 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 100-1073741823
매개 변수 형식 dynamic
문서 temp_buffers

트랜잭션 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 트랜잭션 상태 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다. 이 값을 shared_buffers 분수로 결정하려면 0을 지정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 0-131072
매개 변수 형식 정적
문서 거래_버퍼

진공 버퍼 사용 한도

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, ANALYZE, autovacuum에 대한 버퍼 풀 크기를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 0-16777216
매개 변수 형식 dynamic
문서 vacuum_buffer_usage_limit

work_mem (워크 메모리)

특성 가치
카테고리 리소스 사용량/메모리
Description 쿼리 작업 영역에 사용할 최대 메모리를 설정합니다. 임시 디스크 파일로 전환하기 전에 각 내부 정렬 작업 및 해시 테이블에서 이 많은 메모리를 사용할 수 있습니다.
데이터 형식 integer
기본값 4096
허용되는 값 4096-2097151
매개 변수 형식 dynamic
문서 work_mem

Description

PostgreSQL의 매개 변수는 work_mem 각 데이터베이스 세션의 프라이빗 메모리 영역 내에서 특정 내부 작업에 할당된 메모리 양을 제어합니다. 이러한 작업의 예로는 정렬 및 해시가 있습니다.

공유 메모리 영역에 work_mem 있는 공유 버퍼와 달리 세션당 또는 쿼리별 프라이빗 메모리 공간에 할당됩니다. 적절한 work_mem 크기를 설정하면 이러한 작업의 효율성을 크게 개선하고 디스크에 임시 데이터를 쓸 필요성을 줄일 수 있습니다.

핵심 사항

  • 프라이빗 연결 메모리: work_mem 각 데이터베이스 세션에서 사용하는 프라이빗 메모리의 일부입니다. 이 메모리는 사용하는 공유 메모리 영역 shared_buffers 과 다릅니다.
  • 쿼리별 사용: 모든 세션 또는 쿼리에서 사용하는 work_mem것은 아닙니다. SELECT 1 같은 간단한 쿼리는 work_mem이 필요할 가능성이 낮습니다. 복잡한 쿼리에서 정렬이나 해시 작업을 수행할 때 하나 또는 여러 work_mem 청크를 소모할 수 있습니다.
  • 병렬 작업: 여러 병렬 백 엔드에 걸쳐 있는 쿼리의 경우 각 백 엔드가 하나 또는 여러 work_mem 청크를 사용할 수 있습니다.

work_mem 모니터링 및 조정

주로 정렬 또는 해시 작업과 관련된 쿼리 실행 시간이 느린 경우 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정 work_mem 해야 합니다. Azure Portal에서 사용할 수 있는 도구를 사용하여 성능을 모니터링하는 방법은 다음과 같습니다.

세분화된 조정

매개 변수를 work_mem 관리하는 동안 전역 값을 설정하기보다는 세분화된 조정 방법을 채택하는 것이 더 효율적입니다. 이 방법을 사용하면 프로세스 및 사용자의 특정 요구 사항에 따라 신중하게 메모리를 할당할 수 있습니다. 또한 메모리 부족 문제가 발생할 위험을 최소화합니다. 다음은 이를 실행하는 방법입니다.

  • 사용자 수준: 특정 사용자가 주로 메모리 집약적인 집계 또는 보고 작업에 관련된 경우 해당 사용자의 값을 사용자 지정하는 것이 work_mem 좋습니다. 명령을 ALTER ROLE 사용하여 사용자 작업의 성능을 향상시킵니다.

  • 함수/프로시저 수준: 특정 함수 또는 프로시저가 상당한 임시 파일을 생성하는 경우 특정 함수 또는 프로시저 수준에서 값을 늘리는 work_mem 것이 도움이 될 수 있습니다. ALTER FUNCTION 또는 ALTER PROCEDURE 명령을 사용하여 특히 이러한 작업에 더 많은 메모리를 할당합니다.

  • 데이터베이스 수준: 특정 데이터베이스만 높은 수의 임시 파일을 생성하는 경우 데이터베이스 수준에서 변경 work_mem 합니다.

  • 전역 수준: 시스템을 분석한 결과 대부분의 쿼리가 작은 임시 파일을 생성하는 반면, 소수의 쿼리만 큰 파일을 만드는 경우 전역적으로 값을 늘리는 work_mem 것이 좋습니다. 이 작업을 통해 대부분의 쿼리가 메모리에서 처리할 수 있으므로 디스크 기반 작업을 방지하고 효율성을 향상시킬 수 있습니다. 그러나 항상 주의해야 하며 서버의 메모리 사용률을 모니터링하여 증가된 work_mem 값을 처리할 수 있는지 확인합니다.

정렬 작업에 대한 최소 work_mem 값 결정

특정 쿼리, 특히 정렬 프로세스 중에 임시 디스크 파일을 생성하는 최소 work_mem 값을 찾으려면 먼저 쿼리 실행 중에 생성된 임시 파일 크기를 고려합니다. 예를 들어 쿼리가 20MB 임시 파일을 생성하는 경우:

  1. psql 또는 선호하는 PostgreSQL 클라이언트를 사용하여 데이터베이스에 연결합니다.
  2. 메모리에서 처리할 때 추가 헤더를 고려하도록 초기 work_mem 값을 20MB보다 약간 높게 설정합니다. 다음과 같은 SET work_mem TO '25MB'명령을 사용합니다.
  3. 동일한 세션에서 문제가 있는 쿼리에 대해 EXPLAIN ANALYZE를 실행합니다.
  4. "Sort Method: quicksort Memory: xkB"에 대한 출력을 검토합니다. 만약 "external merge Disk: xkB"가 표시되면, work_mem 값을 점진적으로 올리고 "quicksort Memory"가 나타날 때까지 다시 테스트합니다. 쿼리가 현재 메모리에서 작동 중임을 나타내는 신호로 "quicksort Memory"가 표시됩니다.
  5. 이 메서드를 통해 값을 확인한 후에는 운영 요구 사항에 맞게 전역적으로 또는 보다 세부적인 수준에서 적용할 수 있습니다(앞에서 설명한 대로).

autovacuum_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 각 자동 진공 작업자 프로세스에서 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 -1
허용되는 값 -1-2097151
매개 변수 형식 dynamic
문서 autovacuum_work_mem

커밋 타임스탬프 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 커밋 타임스탬프 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다. 이 값을 shared_buffers 분수로 결정하려면 0을 지정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 0-131072
매개 변수 형식 정적
문서 커밋 타임스탬프 버퍼

동적_공유_메모리_타입

특성 가치
카테고리 리소스 사용량/메모리
Description 사용되는 동적 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 posix
허용되는 값 posix
매개 변수 형식 읽기 전용
문서 동적_공유_메모리_타입

해시 메모리 곱셈기 (hash_mem_multiplier)

특성 가치
카테고리 리소스 사용량/메모리
Description 해시 테이블에 사용할 "work_mem"의 배수입니다.
데이터 형식 numeric
기본값 2
허용되는 값 1-1000
매개 변수 형식 dynamic
문서 hash_mem_multiplier

huge_pages

특성 가치
카테고리 리소스 사용량/메모리
Description Linux 또는 Windows에서 거대한 페이지 사용
데이터 형식 enumeration
기본값 try
허용되는 값 on,off,try
매개 변수 형식 정적
문서 huge_pages

Description

거대한 페이지는 더 큰 블록에서 메모리를 관리할 수 있는 기능입니다. 일반적으로 표준 4KB 페이지와 달리 최대 2MB의 블록을 관리할 수 있습니다.

거대한 페이지를 사용하면 CPU를 효과적으로 오프로드하는 성능 이점을 제공할 수 있습니다.

  • TLB(변환 색인 버퍼) 누락이 줄어드는 등 메모리 관리 작업과 관련된 오버헤드가 감소합니다.
  • 메모리 관리에 필요한 시간을 단축합니다.

특히 PostgreSQL에서는 공유 메모리 영역에 대해서만 거대한 페이지를 사용할 수 있습니다. 공유 메모리 영역의 상당 부분이 공유 버퍼에 할당됩니다.

또 다른 장점은 거대한 페이지가 공유 메모리 영역을 디스크로 교환하지 못하게 하여 성능을 더욱 안정화한다는 것입니다.

Recommendations

  • 메모리 리소스가 많은 서버의 경우 거대한 페이지를 사용하지 않도록 설정하지 마십시오. 거대한 페이지를 사용하지 않도록 설정하면 성능이 저하됩니다.
  • 대규모 페이지를 지원하지 않는 더 작은 서버로 시작하지만, 대규모 페이지를 지원하는 서버로 업그레이드할 계획이 있는 경우, 원활한 전환과 최적의 성능을 위해 huge_pages 설정을 TRY로 유지합니다.

Azure 관련 메모

vCore가 4개 이상인 서버의 경우 기본 운영 체제에서 거대한 페이지가 자동으로 할당됩니다. vCore가 4개 미만인 서버에서는 이 기능을 사용할 수 없습니다. 공유 메모리 설정이 변경되거나 shared_buffers과 같은 세부 사항이 변경되면 대용량 페이지 수가 자동으로 조정됩니다.

huge_page_size (큰 페이지 크기)

특성 가치
카테고리 리소스 사용량/메모리
Description 요청해야 하는 거대한 페이지의 크기입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 huge_page_size

io_combine_limit

특성 가치
카테고리 리소스 사용량/메모리
Description 데이터 읽기 및 쓰기 크기에 제한이 있습니다.
데이터 형식 integer
기본값 16
허용되는 값 16
매개 변수 형식 읽기 전용
문서 io_combine_limit

logical_decoding_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 논리 디코딩에 사용할 최대 메모리를 설정합니다. 각 내부 재정렬 버퍼는 디스크로 넘기기 전에 이 정도의 메모리를 사용할 수 있습니다.
데이터 형식 integer
기본값 65536
허용되는 값 64-2147483647
매개 변수 형식 dynamic
문서 logical_decoding_work_mem

maintenance_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 유지 관리 작업에 사용할 최대 메모리를 설정합니다. 여기에는 VACUUM 및 CREATE INDEX와 같은 작업이 포함됩니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 1024-2097151
매개 변수 형식 dynamic
문서 maintenance_work_mem

Description

maintenance_work_mem 는 PostgreSQL의 구성 매개 변수입니다. 유지 관리 작업에 할당된 메모리 양(예: VACUUM, CREATE INDEX및 ALTER TABLE)을 제어합니다. 쿼리 작업에 대한 메모리 할당에 영향을 주는 것과 달리 work_mem데이터베이스 구조를 유지 관리하고 최적화하는 작업을 위해 예약되어 있습니다 maintenance_work_mem .

! [참고] 지나치게 공격적인 값으로 설정 maintenance_work_mem 하면 시스템에서 메모리 부족 오류가 주기적으로 발생할 수 있습니다. 이 매개 변수를 변경하기 전에 서버에서 사용할 수 있는 메모리 양과 앞에서 설명한 작업에 메모리를 할당할 수 있는 동시 작업 수를 이해하는 것이 매우 중요합니다.

핵심 사항

  • 진공 메모리 한도: maintenance_work_mem를 늘려 데드 튜플의 정리 속도를 높이고자 한다면, VACUUM에 데드 튜플 식별자를 수집하는 데 기본적으로 제한이 내재되어 있다는 점을 유의하세요. 이 프로세스에는 최대 1GB의 메모리만 사용할 수 있습니다.
  • 자동 진공을 위한 메모리 분리: 자동 진공 작업에서 독립적으로 사용하는 메모리를 제어하는 설정을 사용할 autovacuum_work_mem 수 있습니다. 이 설정은 .의 하위 집합으로 작동합니다 maintenance_work_mem. 다른 유지 관리 작업 및 데이터 정의 작업에 대한 메모리 할당에 영향을 주지 않고 자동 진공에서 사용하는 메모리 양을 결정할 수 있습니다.

Azure 관련 메모

maintenance_work_mem 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 maintenance_work_mem 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 maintenance_work_mem 값에 따라 매개 변수 값도 조정해야 합니다.

maintenance_work_mem 값을 계산하는 데 사용되는 수식은 (long)(82.5 * ln(memoryGiB) + 40) * 1024입니다.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 maintenance_work_mem
2GiB 99,328 KiB
4GiB 157,696KiB
8GiB 216,064KiB
16GiB 274,432 KiB
32GiB 332,800KiB
48GiB 367,616 KiB
64GiB 392,192KiB
80GiB 410,624KiB
128GiB 450,560KiB
160GiB 468,992 KiB
192GiB 484,352 KiB
256GiB 508,928 KiB
384GiB 542,720 KiB
432GiB 552,960KiB
672GiB 590,848 KiB

max_prepared_transactions

특성 가치
카테고리 리소스 사용량/메모리
Description 동시에 준비된 최대 트랜잭션 수를 설정합니다.
데이터 형식 integer
기본값 0
허용되는 값 0-262143
매개 변수 형식 정적
문서 max_prepared_transactions

max_stack_depth

특성 가치
카테고리 리소스 사용량/메모리
Description 최대 스택 깊이(킬로바이트)를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 2048
매개 변수 형식 읽기 전용
문서 max_stack_depth

min_dynamic_shared_memory

특성 가치
카테고리 리소스 사용량/메모리
Description 시작 시 예약된 동적 공유 메모리 양입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 min_dynamic_shared_memory

multixact_member_buffers

특성 가치
카테고리 리소스 사용량/메모리
Description MultiXact 멤버 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다.
데이터 형식 integer
기본값 32
허용되는 값 16-131072
매개 변수 형식 정적
문서 multixact_member_buffers

멀티트랜잭트_오프셋_버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description MultiXact 오프셋 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다.
데이터 형식 integer
기본값 16
허용되는 값 16-131072
매개 변수 형식 정적
문서 multixact_offset_buffers (멀티엑스액트 오프셋 버퍼)

알림_버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description LISTEN/NOTIFY 메시지 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다.
데이터 형식 integer
기본값 16
허용되는 값 16-131072
매개 변수 형식 정적
문서 notify_buffers

직렬화 가능 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 직렬화 가능한 트랜잭션 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다.
데이터 형식 integer
기본값 32
허용되는 값 16-131072
매개 변수 형식 정적
문서 serializable_buffers

공유 버퍼 (shared_buffers)

특성 가치
카테고리 리소스 사용량/메모리
Description 서버에서 사용하는 공유 메모리 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 16-1073741823
매개 변수 형식 정적
문서 shared_buffers

Description

구성 매개 변수는 shared_buffers 데이터를 버퍼링하기 위해 PostgreSQL 데이터베이스에 할당된 시스템 메모리 양을 결정합니다. 모든 데이터베이스 프로세스에서 액세스할 수 있는 중앙 집중식 메모리 풀 역할을 합니다.

데이터가 필요한 경우 데이터베이스 프로세스는 먼저 공유 버퍼를 확인합니다. 필요한 데이터가 있는 경우 빠르게 검색되고 시간이 많이 걸리는 디스크 읽기를 무시합니다. 공유 버퍼는 데이터베이스 프로세스와 디스크 간의 중개자 역할을 하며 필요한 I/O 작업의 수를 효과적으로 줄입니다.

Azure 관련 메모

shared_buffers 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 서버 매개 변수에 대한 기본값에 shared_buffers 영향을 주지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 shared_buffers 값에 따라 매개 변수 값도 조정해야 합니다.

최대 2GiB의 메모리가 있는 가상 머신의 경우 값을 shared_buffers 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 16384.

2GiB를 초과하는 가상 머신의 shared_buffers 경우 값을 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 32768.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 공유 버퍼 (shared_buffers)
2GiB 32768
4GiB 131072
8GiB 262144
16GiB 524288
32GiB 1048576
48GiB 1572864
64GiB 2097152
80GiB 2621440
128GiB 4194304
160GiB 5242880
192GiB 6291456
256GiB 8388608
384GiB 12582912
432GiB 14155776
672GiB 22020096

공유_메모리_유형

특성 가치
카테고리 리소스 사용량/메모리
Description 기본 공유 메모리 영역에 사용되는 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 mmap
허용되는 값 mmap
매개 변수 형식 읽기 전용
문서 공유_메모리_타입

subtransaction_buffers

특성 가치
카테고리 리소스 사용량/메모리
Description 하위 변환 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다. 이 값을 shared_buffers 분수로 결정하려면 0을 지정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 0-131072
매개 변수 형식 정적
문서 subtransaction_buffers

임시 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 각 세션에서 사용되는 최대 임시 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 100-1073741823
매개 변수 형식 dynamic
문서 temp_buffers

트랜잭션 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 트랜잭션 상태 캐시에 사용되는 전용 버퍼 풀의 크기를 설정합니다. 이 값을 shared_buffers 분수로 결정하려면 0을 지정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 0-131072
매개 변수 형식 정적
문서 거래_버퍼

진공 버퍼 사용 한도

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, ANALYZE, autovacuum에 대한 버퍼 풀 크기를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 0-16777216
매개 변수 형식 dynamic
문서 vacuum_buffer_usage_limit

work_mem (워크 메모리)

특성 가치
카테고리 리소스 사용량/메모리
Description 쿼리 작업 영역에 사용할 최대 메모리를 설정합니다. 임시 디스크 파일로 전환하기 전에 각 내부 정렬 작업 및 해시 테이블에서 이 많은 메모리를 사용할 수 있습니다.
데이터 형식 integer
기본값 4096
허용되는 값 4096-2097151
매개 변수 형식 dynamic
문서 work_mem

Description

PostgreSQL의 매개 변수는 work_mem 각 데이터베이스 세션의 프라이빗 메모리 영역 내에서 특정 내부 작업에 할당된 메모리 양을 제어합니다. 이러한 작업의 예로는 정렬 및 해시가 있습니다.

공유 메모리 영역에 work_mem 있는 공유 버퍼와 달리 세션당 또는 쿼리별 프라이빗 메모리 공간에 할당됩니다. 적절한 work_mem 크기를 설정하면 이러한 작업의 효율성을 크게 개선하고 디스크에 임시 데이터를 쓸 필요성을 줄일 수 있습니다.

핵심 사항

  • 프라이빗 연결 메모리: work_mem 각 데이터베이스 세션에서 사용하는 프라이빗 메모리의 일부입니다. 이 메모리는 사용하는 공유 메모리 영역 shared_buffers 과 다릅니다.
  • 쿼리별 사용: 모든 세션 또는 쿼리에서 사용하는 work_mem것은 아닙니다. SELECT 1 같은 간단한 쿼리는 work_mem이 필요할 가능성이 낮습니다. 복잡한 쿼리에서 정렬이나 해시 작업을 수행할 때 하나 또는 여러 work_mem 청크를 소모할 수 있습니다.
  • 병렬 작업: 여러 병렬 백 엔드에 걸쳐 있는 쿼리의 경우 각 백 엔드가 하나 또는 여러 work_mem 청크를 사용할 수 있습니다.

work_mem 모니터링 및 조정

주로 정렬 또는 해시 작업과 관련된 쿼리 실행 시간이 느린 경우 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정 work_mem 해야 합니다. Azure Portal에서 사용할 수 있는 도구를 사용하여 성능을 모니터링하는 방법은 다음과 같습니다.

세분화된 조정

매개 변수를 work_mem 관리하는 동안 전역 값을 설정하기보다는 세분화된 조정 방법을 채택하는 것이 더 효율적입니다. 이 방법을 사용하면 프로세스 및 사용자의 특정 요구 사항에 따라 신중하게 메모리를 할당할 수 있습니다. 또한 메모리 부족 문제가 발생할 위험을 최소화합니다. 다음은 이를 실행하는 방법입니다.

  • 사용자 수준: 특정 사용자가 주로 메모리 집약적인 집계 또는 보고 작업에 관련된 경우 해당 사용자의 값을 사용자 지정하는 것이 work_mem 좋습니다. 명령을 ALTER ROLE 사용하여 사용자 작업의 성능을 향상시킵니다.

  • 함수/프로시저 수준: 특정 함수 또는 프로시저가 상당한 임시 파일을 생성하는 경우 특정 함수 또는 프로시저 수준에서 값을 늘리는 work_mem 것이 도움이 될 수 있습니다. ALTER FUNCTION 또는 ALTER PROCEDURE 명령을 사용하여 특히 이러한 작업에 더 많은 메모리를 할당합니다.

  • 데이터베이스 수준: 특정 데이터베이스만 높은 수의 임시 파일을 생성하는 경우 데이터베이스 수준에서 변경 work_mem 합니다.

  • 전역 수준: 시스템을 분석한 결과 대부분의 쿼리가 작은 임시 파일을 생성하는 반면, 소수의 쿼리만 큰 파일을 만드는 경우 전역적으로 값을 늘리는 work_mem 것이 좋습니다. 이 작업을 통해 대부분의 쿼리가 메모리에서 처리할 수 있으므로 디스크 기반 작업을 방지하고 효율성을 향상시킬 수 있습니다. 그러나 항상 주의해야 하며 서버의 메모리 사용률을 모니터링하여 증가된 work_mem 값을 처리할 수 있는지 확인합니다.

정렬 작업에 대한 최소 work_mem 값 결정

특정 쿼리, 특히 정렬 프로세스 중에 임시 디스크 파일을 생성하는 최소 work_mem 값을 찾으려면 먼저 쿼리 실행 중에 생성된 임시 파일 크기를 고려합니다. 예를 들어 쿼리가 20MB 임시 파일을 생성하는 경우:

  1. psql 또는 선호하는 PostgreSQL 클라이언트를 사용하여 데이터베이스에 연결합니다.
  2. 메모리에서 처리할 때 추가 헤더를 고려하도록 초기 work_mem 값을 20MB보다 약간 높게 설정합니다. 다음과 같은 SET work_mem TO '25MB'명령을 사용합니다.
  3. 동일한 세션에서 문제가 있는 쿼리에 대해 EXPLAIN ANALYZE를 실행합니다.
  4. "Sort Method: quicksort Memory: xkB"에 대한 출력을 검토합니다. 만약 "external merge Disk: xkB"가 표시되면, work_mem 값을 점진적으로 올리고 "quicksort Memory"가 나타날 때까지 다시 테스트합니다. 쿼리가 현재 메모리에서 작동 중임을 나타내는 신호로 "quicksort Memory"가 표시됩니다.
  5. 이 메서드를 통해 값을 확인한 후에는 운영 요구 사항에 맞게 전역적으로 또는 보다 세부적인 수준에서 적용할 수 있습니다(앞에서 설명한 대로).

autovacuum_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 각 자동 진공 작업자 프로세스에서 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 -1
허용되는 값 -1-2097151
매개 변수 형식 dynamic
문서 autovacuum_work_mem

동적_공유_메모리_타입

특성 가치
카테고리 리소스 사용량/메모리
Description 사용되는 동적 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 posix
허용되는 값 posix
매개 변수 형식 읽기 전용
문서 동적_공유_메모리_타입

해시 메모리 곱셈기 (hash_mem_multiplier)

특성 가치
카테고리 리소스 사용량/메모리
Description 해시 테이블에 사용할 work_mem의 배수입니다.
데이터 형식 numeric
기본값 2
허용되는 값 1-1000
매개 변수 형식 dynamic
문서 hash_mem_multiplier

huge_pages

특성 가치
카테고리 리소스 사용량/메모리
Description 거대한 메모리 페이지를 사용하거나 사용하지 않도록 설정합니다. 이 설정은 vCore가 4개 미만인 서버에는 적용되지 않습니다.
데이터 형식 enumeration
기본값 try
허용되는 값 on,off,try
매개 변수 형식 정적
문서 huge_pages

Description

거대한 페이지는 더 큰 블록에서 메모리를 관리할 수 있는 기능입니다. 일반적으로 표준 4KB 페이지와 달리 최대 2MB의 블록을 관리할 수 있습니다.

거대한 페이지를 사용하면 CPU를 효과적으로 오프로드하는 성능 이점을 제공할 수 있습니다.

  • TLB(변환 색인 버퍼) 누락이 줄어드는 등 메모리 관리 작업과 관련된 오버헤드가 감소합니다.
  • 메모리 관리에 필요한 시간을 단축합니다.

특히 PostgreSQL에서는 공유 메모리 영역에 대해서만 거대한 페이지를 사용할 수 있습니다. 공유 메모리 영역의 상당 부분이 공유 버퍼에 할당됩니다.

또 다른 장점은 거대한 페이지가 공유 메모리 영역을 디스크로 교환하지 못하게 하여 성능을 더욱 안정화한다는 것입니다.

Recommendations

  • 메모리 리소스가 많은 서버의 경우 거대한 페이지를 사용하지 않도록 설정하지 마십시오. 거대한 페이지를 사용하지 않도록 설정하면 성능이 저하됩니다.
  • 대규모 페이지를 지원하지 않는 더 작은 서버로 시작하지만, 대규모 페이지를 지원하는 서버로 업그레이드할 계획이 있는 경우, 원활한 전환과 최적의 성능을 위해 huge_pages 설정을 TRY로 유지합니다.

Azure 관련 메모

vCore가 4개 이상인 서버의 경우 기본 운영 체제에서 거대한 페이지가 자동으로 할당됩니다. vCore가 4개 미만인 서버에서는 이 기능을 사용할 수 없습니다. 공유 메모리 설정이 변경되거나 shared_buffers과 같은 세부 사항이 변경되면 대용량 페이지 수가 자동으로 조정됩니다.

huge_page_size (큰 페이지 크기)

특성 가치
카테고리 리소스 사용량/메모리
Description 요청해야 하는 거대한 페이지의 크기입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 huge_page_size

logical_decoding_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 논리 디코딩에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 65536
허용되는 값 64-2147483647
매개 변수 형식 dynamic
문서 logical_decoding_work_mem

maintenance_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, 인덱스 만들기와 같은 유지 관리 작업에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 1024-2097151
매개 변수 형식 dynamic
문서 maintenance_work_mem

Description

maintenance_work_mem 는 PostgreSQL의 구성 매개 변수입니다. 유지 관리 작업에 할당된 메모리 양(예: VACUUM, CREATE INDEX및 ALTER TABLE)을 제어합니다. 쿼리 작업에 대한 메모리 할당에 영향을 주는 것과 달리 work_mem데이터베이스 구조를 유지 관리하고 최적화하는 작업을 위해 예약되어 있습니다 maintenance_work_mem .

! [참고] 지나치게 공격적인 값으로 설정 maintenance_work_mem 하면 시스템에서 메모리 부족 오류가 주기적으로 발생할 수 있습니다. 이 매개 변수를 변경하기 전에 서버에서 사용할 수 있는 메모리 양과 앞에서 설명한 작업에 메모리를 할당할 수 있는 동시 작업 수를 이해하는 것이 매우 중요합니다.

핵심 사항

  • 진공 메모리 한도: maintenance_work_mem를 늘려 데드 튜플의 정리 속도를 높이고자 한다면, VACUUM에 데드 튜플 식별자를 수집하는 데 기본적으로 제한이 내재되어 있다는 점을 유의하세요. 이 프로세스에는 최대 1GB의 메모리만 사용할 수 있습니다.
  • 자동 진공을 위한 메모리 분리: 자동 진공 작업에서 독립적으로 사용하는 메모리를 제어하는 설정을 사용할 autovacuum_work_mem 수 있습니다. 이 설정은 .의 하위 집합으로 작동합니다 maintenance_work_mem. 다른 유지 관리 작업 및 데이터 정의 작업에 대한 메모리 할당에 영향을 주지 않고 자동 진공에서 사용하는 메모리 양을 결정할 수 있습니다.

Azure 관련 메모

maintenance_work_mem 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 maintenance_work_mem 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 maintenance_work_mem 값에 따라 매개 변수 값도 조정해야 합니다.

maintenance_work_mem 값을 계산하는 데 사용되는 수식은 (long)(82.5 * ln(memoryGiB) + 40) * 1024입니다.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 maintenance_work_mem
2GiB 99,328 KiB
4GiB 157,696KiB
8GiB 216,064KiB
16GiB 274,432 KiB
32GiB 332,800KiB
48GiB 367,616 KiB
64GiB 392,192KiB
80GiB 410,624KiB
128GiB 450,560KiB
160GiB 468,992 KiB
192GiB 484,352 KiB
256GiB 508,928 KiB
384GiB 542,720 KiB
432GiB 552,960KiB
672GiB 590,848 KiB

max_prepared_transactions

특성 가치
카테고리 리소스 사용량/메모리
Description 동시에 준비된 최대 트랜잭션 수를 설정합니다. 복제본 서버를 실행하는 경우 이 매개 변수를 기본 서버의 값 이상으로 설정해야 합니다.
데이터 형식 integer
기본값 0
허용되는 값 0-262143
매개 변수 형식 정적
문서 max_prepared_transactions

max_stack_depth

특성 가치
카테고리 리소스 사용량/메모리
Description 최대 스택 깊이(킬로바이트)를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 2048
매개 변수 형식 읽기 전용
문서 max_stack_depth

min_dynamic_shared_memory

특성 가치
카테고리 리소스 사용량/메모리
Description 시작 시 예약된 동적 공유 메모리 양입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 min_dynamic_shared_memory

공유 버퍼 (shared_buffers)

특성 가치
카테고리 리소스 사용량/메모리
Description 서버에서 사용하는 공유 메모리 버퍼 수를 설정합니다. 단위는 8kb입니다. 허용되는 값은 사용 가능한 메모리의 10% - 75% 범위 내에 있습니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 16-1073741823
매개 변수 형식 정적
문서 shared_buffers

Description

구성 매개 변수는 shared_buffers 데이터를 버퍼링하기 위해 PostgreSQL 데이터베이스에 할당된 시스템 메모리 양을 결정합니다. 모든 데이터베이스 프로세스에서 액세스할 수 있는 중앙 집중식 메모리 풀 역할을 합니다.

데이터가 필요한 경우 데이터베이스 프로세스는 먼저 공유 버퍼를 확인합니다. 필요한 데이터가 있는 경우 빠르게 검색되고 시간이 많이 걸리는 디스크 읽기를 무시합니다. 공유 버퍼는 데이터베이스 프로세스와 디스크 간의 중개자 역할을 하며 필요한 I/O 작업의 수를 효과적으로 줄입니다.

Azure 관련 메모

shared_buffers 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 서버 매개 변수에 대한 기본값에 shared_buffers 영향을 주지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 shared_buffers 값에 따라 매개 변수 값도 조정해야 합니다.

최대 2GiB의 메모리가 있는 가상 머신의 경우 값을 shared_buffers 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 16384.

2GiB를 초과하는 가상 머신의 shared_buffers 경우 값을 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 32768.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 공유 버퍼 (shared_buffers)
2GiB 32768
4GiB 131072
8GiB 262144
16GiB 524288
32GiB 1048576
48GiB 1572864
64GiB 2097152
80GiB 2621440
128GiB 4194304
160GiB 5242880
192GiB 6291456
256GiB 8388608
384GiB 12582912
432GiB 14155776
672GiB 22020096

공유_메모리_유형

특성 가치
카테고리 리소스 사용량/메모리
Description 기본 공유 메모리 영역에 사용되는 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 mmap
허용되는 값 mmap
매개 변수 형식 읽기 전용
문서 공유_메모리_타입

임시 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 각 데이터베이스 세션에서 사용하는 최대 임시 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 100-1073741823
매개 변수 형식 dynamic
문서 temp_buffers

진공 버퍼 사용 한도

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, ANALYZE, autovacuum에 대한 버퍼 풀 크기를 설정합니다.
데이터 형식 integer
기본값 256
허용되는 값 0-16777216
매개 변수 형식 dynamic
문서 vacuum_buffer_usage_limit

work_mem (워크 메모리)

특성 가치
카테고리 리소스 사용량/메모리
Description 임시 디스크 파일에 쓰기 전에 내부 정렬 작업 및 해시 테이블에서 사용할 메모리 양을 설정합니다.
데이터 형식 integer
기본값 4096
허용되는 값 4096-2097151
매개 변수 형식 dynamic
문서 work_mem

Description

PostgreSQL의 매개 변수는 work_mem 각 데이터베이스 세션의 프라이빗 메모리 영역 내에서 특정 내부 작업에 할당된 메모리 양을 제어합니다. 이러한 작업의 예로는 정렬 및 해시가 있습니다.

공유 메모리 영역에 work_mem 있는 공유 버퍼와 달리 세션당 또는 쿼리별 프라이빗 메모리 공간에 할당됩니다. 적절한 work_mem 크기를 설정하면 이러한 작업의 효율성을 크게 개선하고 디스크에 임시 데이터를 쓸 필요성을 줄일 수 있습니다.

핵심 사항

  • 프라이빗 연결 메모리: work_mem 각 데이터베이스 세션에서 사용하는 프라이빗 메모리의 일부입니다. 이 메모리는 사용하는 공유 메모리 영역 shared_buffers 과 다릅니다.
  • 쿼리별 사용: 모든 세션 또는 쿼리에서 사용하는 work_mem것은 아닙니다. SELECT 1 같은 간단한 쿼리는 work_mem이 필요할 가능성이 낮습니다. 복잡한 쿼리에서 정렬이나 해시 작업을 수행할 때 하나 또는 여러 work_mem 청크를 소모할 수 있습니다.
  • 병렬 작업: 여러 병렬 백 엔드에 걸쳐 있는 쿼리의 경우 각 백 엔드가 하나 또는 여러 work_mem 청크를 사용할 수 있습니다.

work_mem 모니터링 및 조정

주로 정렬 또는 해시 작업과 관련된 쿼리 실행 시간이 느린 경우 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정 work_mem 해야 합니다. Azure Portal에서 사용할 수 있는 도구를 사용하여 성능을 모니터링하는 방법은 다음과 같습니다.

세분화된 조정

매개 변수를 work_mem 관리하는 동안 전역 값을 설정하기보다는 세분화된 조정 방법을 채택하는 것이 더 효율적입니다. 이 방법을 사용하면 프로세스 및 사용자의 특정 요구 사항에 따라 신중하게 메모리를 할당할 수 있습니다. 또한 메모리 부족 문제가 발생할 위험을 최소화합니다. 다음은 이를 실행하는 방법입니다.

  • 사용자 수준: 특정 사용자가 주로 메모리 집약적인 집계 또는 보고 작업에 관련된 경우 해당 사용자의 값을 사용자 지정하는 것이 work_mem 좋습니다. 명령을 ALTER ROLE 사용하여 사용자 작업의 성능을 향상시킵니다.

  • 함수/프로시저 수준: 특정 함수 또는 프로시저가 상당한 임시 파일을 생성하는 경우 특정 함수 또는 프로시저 수준에서 값을 늘리는 work_mem 것이 도움이 될 수 있습니다. ALTER FUNCTION 또는 ALTER PROCEDURE 명령을 사용하여 특히 이러한 작업에 더 많은 메모리를 할당합니다.

  • 데이터베이스 수준: 특정 데이터베이스만 높은 수의 임시 파일을 생성하는 경우 데이터베이스 수준에서 변경 work_mem 합니다.

  • 전역 수준: 시스템을 분석한 결과 대부분의 쿼리가 작은 임시 파일을 생성하는 반면, 소수의 쿼리만 큰 파일을 만드는 경우 전역적으로 값을 늘리는 work_mem 것이 좋습니다. 이 작업을 통해 대부분의 쿼리가 메모리에서 처리할 수 있으므로 디스크 기반 작업을 방지하고 효율성을 향상시킬 수 있습니다. 그러나 항상 주의해야 하며 서버의 메모리 사용률을 모니터링하여 증가된 work_mem 값을 처리할 수 있는지 확인합니다.

정렬 작업에 대한 최소 work_mem 값 결정

특정 쿼리, 특히 정렬 프로세스 중에 임시 디스크 파일을 생성하는 최소 work_mem 값을 찾으려면 먼저 쿼리 실행 중에 생성된 임시 파일 크기를 고려합니다. 예를 들어 쿼리가 20MB 임시 파일을 생성하는 경우:

  1. psql 또는 선호하는 PostgreSQL 클라이언트를 사용하여 데이터베이스에 연결합니다.
  2. 메모리에서 처리할 때 추가 헤더를 고려하도록 초기 work_mem 값을 20MB보다 약간 높게 설정합니다. 다음과 같은 SET work_mem TO '25MB'명령을 사용합니다.
  3. 동일한 세션에서 문제가 있는 쿼리에 대해 EXPLAIN ANALYZE를 실행합니다.
  4. "Sort Method: quicksort Memory: xkB"에 대한 출력을 검토합니다. 만약 "external merge Disk: xkB"가 표시되면, work_mem 값을 점진적으로 올리고 "quicksort Memory"가 나타날 때까지 다시 테스트합니다. 쿼리가 현재 메모리에서 작동 중임을 나타내는 신호로 "quicksort Memory"가 표시됩니다.
  5. 이 메서드를 통해 값을 확인한 후에는 운영 요구 사항에 맞게 전역적으로 또는 보다 세부적인 수준에서 적용할 수 있습니다(앞에서 설명한 대로).

autovacuum_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 각 자동 진공 작업자 프로세스에서 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 -1
허용되는 값 -1-2097151
매개 변수 형식 dynamic
문서 autovacuum_work_mem

동적_공유_메모리_타입

특성 가치
카테고리 리소스 사용량/메모리
Description 사용되는 동적 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 posix
허용되는 값 posix
매개 변수 형식 읽기 전용
문서 동적_공유_메모리_타입

해시 메모리 곱셈기 (hash_mem_multiplier)

특성 가치
카테고리 리소스 사용량/메모리
Description 해시 테이블에 사용할 work_mem의 배수입니다.
데이터 형식 numeric
기본값 2
허용되는 값 1-1000
매개 변수 형식 dynamic
문서 hash_mem_multiplier

huge_pages

특성 가치
카테고리 리소스 사용량/메모리
Description 거대한 메모리 페이지를 사용하거나 사용하지 않도록 설정합니다. 이 설정은 vCore가 4개 미만인 서버에는 적용되지 않습니다.
데이터 형식 enumeration
기본값 try
허용되는 값 on,off,try
매개 변수 형식 정적
문서 huge_pages

Description

거대한 페이지는 더 큰 블록에서 메모리를 관리할 수 있는 기능입니다. 일반적으로 표준 4KB 페이지와 달리 최대 2MB의 블록을 관리할 수 있습니다.

거대한 페이지를 사용하면 CPU를 효과적으로 오프로드하는 성능 이점을 제공할 수 있습니다.

  • TLB(변환 색인 버퍼) 누락이 줄어드는 등 메모리 관리 작업과 관련된 오버헤드가 감소합니다.
  • 메모리 관리에 필요한 시간을 단축합니다.

특히 PostgreSQL에서는 공유 메모리 영역에 대해서만 거대한 페이지를 사용할 수 있습니다. 공유 메모리 영역의 상당 부분이 공유 버퍼에 할당됩니다.

또 다른 장점은 거대한 페이지가 공유 메모리 영역을 디스크로 교환하지 못하게 하여 성능을 더욱 안정화한다는 것입니다.

Recommendations

  • 메모리 리소스가 많은 서버의 경우 거대한 페이지를 사용하지 않도록 설정하지 마십시오. 거대한 페이지를 사용하지 않도록 설정하면 성능이 저하됩니다.
  • 대규모 페이지를 지원하지 않는 더 작은 서버로 시작하지만, 대규모 페이지를 지원하는 서버로 업그레이드할 계획이 있는 경우, 원활한 전환과 최적의 성능을 위해 huge_pages 설정을 TRY로 유지합니다.

Azure 관련 메모

vCore가 4개 이상인 서버의 경우 기본 운영 체제에서 거대한 페이지가 자동으로 할당됩니다. vCore가 4개 미만인 서버에서는 이 기능을 사용할 수 없습니다. 공유 메모리 설정이 변경되거나 shared_buffers과 같은 세부 사항이 변경되면 대용량 페이지 수가 자동으로 조정됩니다.

huge_page_size (큰 페이지 크기)

특성 가치
카테고리 리소스 사용량/메모리
Description 요청해야 하는 거대한 페이지의 크기입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 huge_page_size

logical_decoding_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 논리 디코딩에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 65536
허용되는 값 64-2147483647
매개 변수 형식 dynamic
문서 logical_decoding_work_mem

maintenance_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, 인덱스 만들기와 같은 유지 관리 작업에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 1024-2097151
매개 변수 형식 dynamic
문서 maintenance_work_mem

Description

maintenance_work_mem 는 PostgreSQL의 구성 매개 변수입니다. 유지 관리 작업에 할당된 메모리 양(예: VACUUM, CREATE INDEX및 ALTER TABLE)을 제어합니다. 쿼리 작업에 대한 메모리 할당에 영향을 주는 것과 달리 work_mem데이터베이스 구조를 유지 관리하고 최적화하는 작업을 위해 예약되어 있습니다 maintenance_work_mem .

! [참고] 지나치게 공격적인 값으로 설정 maintenance_work_mem 하면 시스템에서 메모리 부족 오류가 주기적으로 발생할 수 있습니다. 이 매개 변수를 변경하기 전에 서버에서 사용할 수 있는 메모리 양과 앞에서 설명한 작업에 메모리를 할당할 수 있는 동시 작업 수를 이해하는 것이 매우 중요합니다.

핵심 사항

  • 진공 메모리 한도: maintenance_work_mem를 늘려 데드 튜플의 정리 속도를 높이고자 한다면, VACUUM에 데드 튜플 식별자를 수집하는 데 기본적으로 제한이 내재되어 있다는 점을 유의하세요. 이 프로세스에는 최대 1GB의 메모리만 사용할 수 있습니다.
  • 자동 진공을 위한 메모리 분리: 자동 진공 작업에서 독립적으로 사용하는 메모리를 제어하는 설정을 사용할 autovacuum_work_mem 수 있습니다. 이 설정은 .의 하위 집합으로 작동합니다 maintenance_work_mem. 다른 유지 관리 작업 및 데이터 정의 작업에 대한 메모리 할당에 영향을 주지 않고 자동 진공에서 사용하는 메모리 양을 결정할 수 있습니다.

Azure 관련 메모

maintenance_work_mem 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 maintenance_work_mem 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 maintenance_work_mem 값에 따라 매개 변수 값도 조정해야 합니다.

maintenance_work_mem 값을 계산하는 데 사용되는 수식은 (long)(82.5 * ln(memoryGiB) + 40) * 1024입니다.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 maintenance_work_mem
2GiB 99,328 KiB
4GiB 157,696KiB
8GiB 216,064KiB
16GiB 274,432 KiB
32GiB 332,800KiB
48GiB 367,616 KiB
64GiB 392,192KiB
80GiB 410,624KiB
128GiB 450,560KiB
160GiB 468,992 KiB
192GiB 484,352 KiB
256GiB 508,928 KiB
384GiB 542,720 KiB
432GiB 552,960KiB
672GiB 590,848 KiB

max_prepared_transactions

특성 가치
카테고리 리소스 사용량/메모리
Description 동시에 준비된 최대 트랜잭션 수를 설정합니다. 복제본 서버를 실행하는 경우 이 매개 변수를 기본 서버의 값 이상으로 설정해야 합니다.
데이터 형식 integer
기본값 0
허용되는 값 0-262143
매개 변수 형식 정적
문서 max_prepared_transactions

max_stack_depth

특성 가치
카테고리 리소스 사용량/메모리
Description 최대 스택 깊이(킬로바이트)를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 2048
매개 변수 형식 읽기 전용
문서 max_stack_depth

min_dynamic_shared_memory

특성 가치
카테고리 리소스 사용량/메모리
Description 시작 시 예약된 동적 공유 메모리 양입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 min_dynamic_shared_memory

공유 버퍼 (shared_buffers)

특성 가치
카테고리 리소스 사용량/메모리
Description 서버에서 사용하는 공유 메모리 버퍼 수를 설정합니다. 단위는 8kb입니다. 허용되는 값은 사용 가능한 메모리의 10% - 75% 범위 내에 있습니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 16-1073741823
매개 변수 형식 정적
문서 shared_buffers

Description

구성 매개 변수는 shared_buffers 데이터를 버퍼링하기 위해 PostgreSQL 데이터베이스에 할당된 시스템 메모리 양을 결정합니다. 모든 데이터베이스 프로세스에서 액세스할 수 있는 중앙 집중식 메모리 풀 역할을 합니다.

데이터가 필요한 경우 데이터베이스 프로세스는 먼저 공유 버퍼를 확인합니다. 필요한 데이터가 있는 경우 빠르게 검색되고 시간이 많이 걸리는 디스크 읽기를 무시합니다. 공유 버퍼는 데이터베이스 프로세스와 디스크 간의 중개자 역할을 하며 필요한 I/O 작업의 수를 효과적으로 줄입니다.

Azure 관련 메모

shared_buffers 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 서버 매개 변수에 대한 기본값에 shared_buffers 영향을 주지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 shared_buffers 값에 따라 매개 변수 값도 조정해야 합니다.

최대 2GiB의 메모리가 있는 가상 머신의 경우 값을 shared_buffers 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 16384.

2GiB를 초과하는 가상 머신의 shared_buffers 경우 값을 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 32768.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 공유 버퍼 (shared_buffers)
2GiB 32768
4GiB 131072
8GiB 262144
16GiB 524288
32GiB 1048576
48GiB 1572864
64GiB 2097152
80GiB 2621440
128GiB 4194304
160GiB 5242880
192GiB 6291456
256GiB 8388608
384GiB 12582912
432GiB 14155776
672GiB 22020096

공유_메모리_유형

특성 가치
카테고리 리소스 사용량/메모리
Description 기본 공유 메모리 영역에 사용되는 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 mmap
허용되는 값 mmap
매개 변수 형식 읽기 전용
문서 공유_메모리_타입

임시 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 각 데이터베이스 세션에서 사용하는 최대 임시 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 100-1073741823
매개 변수 형식 dynamic
문서 temp_buffers

work_mem (워크 메모리)

특성 가치
카테고리 리소스 사용량/메모리
Description 임시 디스크 파일에 쓰기 전에 내부 정렬 작업 및 해시 테이블에서 사용할 메모리 양을 설정합니다.
데이터 형식 integer
기본값 4096
허용되는 값 4096-2097151
매개 변수 형식 dynamic
문서 work_mem

Description

PostgreSQL의 매개 변수는 work_mem 각 데이터베이스 세션의 프라이빗 메모리 영역 내에서 특정 내부 작업에 할당된 메모리 양을 제어합니다. 이러한 작업의 예로는 정렬 및 해시가 있습니다.

공유 메모리 영역에 work_mem 있는 공유 버퍼와 달리 세션당 또는 쿼리별 프라이빗 메모리 공간에 할당됩니다. 적절한 work_mem 크기를 설정하면 이러한 작업의 효율성을 크게 개선하고 디스크에 임시 데이터를 쓸 필요성을 줄일 수 있습니다.

핵심 사항

  • 프라이빗 연결 메모리: work_mem 각 데이터베이스 세션에서 사용하는 프라이빗 메모리의 일부입니다. 이 메모리는 사용하는 공유 메모리 영역 shared_buffers 과 다릅니다.
  • 쿼리별 사용: 모든 세션 또는 쿼리에서 사용하는 work_mem것은 아닙니다. SELECT 1 같은 간단한 쿼리는 work_mem이 필요할 가능성이 낮습니다. 복잡한 쿼리에서 정렬이나 해시 작업을 수행할 때 하나 또는 여러 work_mem 청크를 소모할 수 있습니다.
  • 병렬 작업: 여러 병렬 백 엔드에 걸쳐 있는 쿼리의 경우 각 백 엔드가 하나 또는 여러 work_mem 청크를 사용할 수 있습니다.

work_mem 모니터링 및 조정

주로 정렬 또는 해시 작업과 관련된 쿼리 실행 시간이 느린 경우 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정 work_mem 해야 합니다. Azure Portal에서 사용할 수 있는 도구를 사용하여 성능을 모니터링하는 방법은 다음과 같습니다.

세분화된 조정

매개 변수를 work_mem 관리하는 동안 전역 값을 설정하기보다는 세분화된 조정 방법을 채택하는 것이 더 효율적입니다. 이 방법을 사용하면 프로세스 및 사용자의 특정 요구 사항에 따라 신중하게 메모리를 할당할 수 있습니다. 또한 메모리 부족 문제가 발생할 위험을 최소화합니다. 다음은 이를 실행하는 방법입니다.

  • 사용자 수준: 특정 사용자가 주로 메모리 집약적인 집계 또는 보고 작업에 관련된 경우 해당 사용자의 값을 사용자 지정하는 것이 work_mem 좋습니다. 명령을 ALTER ROLE 사용하여 사용자 작업의 성능을 향상시킵니다.

  • 함수/프로시저 수준: 특정 함수 또는 프로시저가 상당한 임시 파일을 생성하는 경우 특정 함수 또는 프로시저 수준에서 값을 늘리는 work_mem 것이 도움이 될 수 있습니다. ALTER FUNCTION 또는 ALTER PROCEDURE 명령을 사용하여 특히 이러한 작업에 더 많은 메모리를 할당합니다.

  • 데이터베이스 수준: 특정 데이터베이스만 높은 수의 임시 파일을 생성하는 경우 데이터베이스 수준에서 변경 work_mem 합니다.

  • 전역 수준: 시스템을 분석한 결과 대부분의 쿼리가 작은 임시 파일을 생성하는 반면, 소수의 쿼리만 큰 파일을 만드는 경우 전역적으로 값을 늘리는 work_mem 것이 좋습니다. 이 작업을 통해 대부분의 쿼리가 메모리에서 처리할 수 있으므로 디스크 기반 작업을 방지하고 효율성을 향상시킬 수 있습니다. 그러나 항상 주의해야 하며 서버의 메모리 사용률을 모니터링하여 증가된 work_mem 값을 처리할 수 있는지 확인합니다.

정렬 작업에 대한 최소 work_mem 값 결정

특정 쿼리, 특히 정렬 프로세스 중에 임시 디스크 파일을 생성하는 최소 work_mem 값을 찾으려면 먼저 쿼리 실행 중에 생성된 임시 파일 크기를 고려합니다. 예를 들어 쿼리가 20MB 임시 파일을 생성하는 경우:

  1. psql 또는 선호하는 PostgreSQL 클라이언트를 사용하여 데이터베이스에 연결합니다.
  2. 메모리에서 처리할 때 추가 헤더를 고려하도록 초기 work_mem 값을 20MB보다 약간 높게 설정합니다. 다음과 같은 SET work_mem TO '25MB'명령을 사용합니다.
  3. 동일한 세션에서 문제가 있는 쿼리에 대해 EXPLAIN ANALYZE를 실행합니다.
  4. "Sort Method: quicksort Memory: xkB"에 대한 출력을 검토합니다. 만약 "external merge Disk: xkB"가 표시되면, work_mem 값을 점진적으로 올리고 "quicksort Memory"가 나타날 때까지 다시 테스트합니다. 쿼리가 현재 메모리에서 작동 중임을 나타내는 신호로 "quicksort Memory"가 표시됩니다.
  5. 이 메서드를 통해 값을 확인한 후에는 운영 요구 사항에 맞게 전역적으로 또는 보다 세부적인 수준에서 적용할 수 있습니다(앞에서 설명한 대로).

autovacuum_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 각 자동 진공 작업자 프로세스에서 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 -1
허용되는 값 -1-2097151
매개 변수 형식 dynamic
문서 autovacuum_work_mem

동적_공유_메모리_타입

특성 가치
카테고리 리소스 사용량/메모리
Description 사용되는 동적 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 posix
허용되는 값 posix
매개 변수 형식 읽기 전용
문서 동적_공유_메모리_타입

해시 메모리 곱셈기 (hash_mem_multiplier)

특성 가치
카테고리 리소스 사용량/메모리
Description 해시 테이블에 사용할 work_mem의 배수입니다.
데이터 형식 numeric
기본값 1
허용되는 값 1-1000
매개 변수 형식 dynamic
문서 hash_mem_multiplier

huge_pages

특성 가치
카테고리 리소스 사용량/메모리
Description 거대한 메모리 페이지를 사용하거나 사용하지 않도록 설정합니다. 이 설정은 vCore가 4개 미만인 서버에는 적용되지 않습니다.
데이터 형식 enumeration
기본값 try
허용되는 값 on,off,try
매개 변수 형식 정적
문서 huge_pages

Description

거대한 페이지는 더 큰 블록에서 메모리를 관리할 수 있는 기능입니다. 일반적으로 표준 4KB 페이지와 달리 최대 2MB의 블록을 관리할 수 있습니다.

거대한 페이지를 사용하면 CPU를 효과적으로 오프로드하는 성능 이점을 제공할 수 있습니다.

  • TLB(변환 색인 버퍼) 누락이 줄어드는 등 메모리 관리 작업과 관련된 오버헤드가 감소합니다.
  • 메모리 관리에 필요한 시간을 단축합니다.

특히 PostgreSQL에서는 공유 메모리 영역에 대해서만 거대한 페이지를 사용할 수 있습니다. 공유 메모리 영역의 상당 부분이 공유 버퍼에 할당됩니다.

또 다른 장점은 거대한 페이지가 공유 메모리 영역을 디스크로 교환하지 못하게 하여 성능을 더욱 안정화한다는 것입니다.

Recommendations

  • 메모리 리소스가 많은 서버의 경우 거대한 페이지를 사용하지 않도록 설정하지 마십시오. 거대한 페이지를 사용하지 않도록 설정하면 성능이 저하됩니다.
  • 대규모 페이지를 지원하지 않는 더 작은 서버로 시작하지만, 대규모 페이지를 지원하는 서버로 업그레이드할 계획이 있는 경우, 원활한 전환과 최적의 성능을 위해 huge_pages 설정을 TRY로 유지합니다.

Azure 관련 메모

vCore가 4개 이상인 서버의 경우 기본 운영 체제에서 거대한 페이지가 자동으로 할당됩니다. vCore가 4개 미만인 서버에서는 이 기능을 사용할 수 없습니다. 공유 메모리 설정이 변경되거나 shared_buffers과 같은 세부 사항이 변경되면 대용량 페이지 수가 자동으로 조정됩니다.

huge_page_size (큰 페이지 크기)

특성 가치
카테고리 리소스 사용량/메모리
Description 요청해야 하는 거대한 페이지의 크기입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 huge_page_size

logical_decoding_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 논리 디코딩에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 65536
허용되는 값 64-2147483647
매개 변수 형식 dynamic
문서 logical_decoding_work_mem

maintenance_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, 인덱스 만들기와 같은 유지 관리 작업에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 1024-2097151
매개 변수 형식 dynamic
문서 maintenance_work_mem

Description

maintenance_work_mem 는 PostgreSQL의 구성 매개 변수입니다. 유지 관리 작업에 할당된 메모리 양(예: VACUUM, CREATE INDEX및 ALTER TABLE)을 제어합니다. 쿼리 작업에 대한 메모리 할당에 영향을 주는 것과 달리 work_mem데이터베이스 구조를 유지 관리하고 최적화하는 작업을 위해 예약되어 있습니다 maintenance_work_mem .

! [참고] 지나치게 공격적인 값으로 설정 maintenance_work_mem 하면 시스템에서 메모리 부족 오류가 주기적으로 발생할 수 있습니다. 이 매개 변수를 변경하기 전에 서버에서 사용할 수 있는 메모리 양과 앞에서 설명한 작업에 메모리를 할당할 수 있는 동시 작업 수를 이해하는 것이 매우 중요합니다.

핵심 사항

  • 진공 메모리 한도: maintenance_work_mem를 늘려 데드 튜플의 정리 속도를 높이고자 한다면, VACUUM에 데드 튜플 식별자를 수집하는 데 기본적으로 제한이 내재되어 있다는 점을 유의하세요. 이 프로세스에는 최대 1GB의 메모리만 사용할 수 있습니다.
  • 자동 진공을 위한 메모리 분리: 자동 진공 작업에서 독립적으로 사용하는 메모리를 제어하는 설정을 사용할 autovacuum_work_mem 수 있습니다. 이 설정은 .의 하위 집합으로 작동합니다 maintenance_work_mem. 다른 유지 관리 작업 및 데이터 정의 작업에 대한 메모리 할당에 영향을 주지 않고 자동 진공에서 사용하는 메모리 양을 결정할 수 있습니다.

Azure 관련 메모

maintenance_work_mem 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 maintenance_work_mem 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 maintenance_work_mem 값에 따라 매개 변수 값도 조정해야 합니다.

maintenance_work_mem 값을 계산하는 데 사용되는 수식은 (long)(82.5 * ln(memoryGiB) + 40) * 1024입니다.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 maintenance_work_mem
2GiB 99,328 KiB
4GiB 157,696KiB
8GiB 216,064KiB
16GiB 274,432 KiB
32GiB 332,800KiB
48GiB 367,616 KiB
64GiB 392,192KiB
80GiB 410,624KiB
128GiB 450,560KiB
160GiB 468,992 KiB
192GiB 484,352 KiB
256GiB 508,928 KiB
384GiB 542,720 KiB
432GiB 552,960KiB
672GiB 590,848 KiB

max_prepared_transactions

특성 가치
카테고리 리소스 사용량/메모리
Description 동시에 준비된 최대 트랜잭션 수를 설정합니다. 복제본 서버를 실행하는 경우 이 매개 변수를 기본 서버의 값 이상으로 설정해야 합니다.
데이터 형식 integer
기본값 0
허용되는 값 0-262143
매개 변수 형식 정적
문서 max_prepared_transactions

max_stack_depth

특성 가치
카테고리 리소스 사용량/메모리
Description 최대 스택 깊이(킬로바이트)를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 2048
매개 변수 형식 읽기 전용
문서 max_stack_depth

min_dynamic_shared_memory

특성 가치
카테고리 리소스 사용량/메모리
Description 시작 시 예약된 동적 공유 메모리 양입니다.
데이터 형식 integer
기본값 0
허용되는 값 0
매개 변수 형식 읽기 전용
문서 min_dynamic_shared_memory

공유 버퍼 (shared_buffers)

특성 가치
카테고리 리소스 사용량/메모리
Description 서버에서 사용하는 공유 메모리 버퍼 수를 설정합니다. 단위는 8kb입니다. 허용되는 값은 사용 가능한 메모리의 10% - 75% 범위 내에 있습니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 16-1073741823
매개 변수 형식 정적
문서 shared_buffers

Description

구성 매개 변수는 shared_buffers 데이터를 버퍼링하기 위해 PostgreSQL 데이터베이스에 할당된 시스템 메모리 양을 결정합니다. 모든 데이터베이스 프로세스에서 액세스할 수 있는 중앙 집중식 메모리 풀 역할을 합니다.

데이터가 필요한 경우 데이터베이스 프로세스는 먼저 공유 버퍼를 확인합니다. 필요한 데이터가 있는 경우 빠르게 검색되고 시간이 많이 걸리는 디스크 읽기를 무시합니다. 공유 버퍼는 데이터베이스 프로세스와 디스크 간의 중개자 역할을 하며 필요한 I/O 작업의 수를 효과적으로 줄입니다.

Azure 관련 메모

shared_buffers 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 서버 매개 변수에 대한 기본값에 shared_buffers 영향을 주지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 shared_buffers 값에 따라 매개 변수 값도 조정해야 합니다.

최대 2GiB의 메모리가 있는 가상 머신의 경우 값을 shared_buffers 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 16384.

2GiB를 초과하는 가상 머신의 shared_buffers 경우 값을 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 32768.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 공유 버퍼 (shared_buffers)
2GiB 32768
4GiB 131072
8GiB 262144
16GiB 524288
32GiB 1048576
48GiB 1572864
64GiB 2097152
80GiB 2621440
128GiB 4194304
160GiB 5242880
192GiB 6291456
256GiB 8388608
384GiB 12582912
432GiB 14155776
672GiB 22020096

공유_메모리_유형

특성 가치
카테고리 리소스 사용량/메모리
Description 기본 공유 메모리 영역에 사용되는 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 mmap
허용되는 값 mmap
매개 변수 형식 읽기 전용
문서 공유_메모리_타입

임시 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 각 데이터베이스 세션에서 사용하는 최대 임시 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 100-1073741823
매개 변수 형식 dynamic
문서 temp_buffers

work_mem (워크 메모리)

특성 가치
카테고리 리소스 사용량/메모리
Description 임시 디스크 파일에 쓰기 전에 내부 정렬 작업 및 해시 테이블에서 사용할 메모리 양을 설정합니다.
데이터 형식 integer
기본값 4096
허용되는 값 4096-2097151
매개 변수 형식 dynamic
문서 work_mem

Description

PostgreSQL의 매개 변수는 work_mem 각 데이터베이스 세션의 프라이빗 메모리 영역 내에서 특정 내부 작업에 할당된 메모리 양을 제어합니다. 이러한 작업의 예로는 정렬 및 해시가 있습니다.

공유 메모리 영역에 work_mem 있는 공유 버퍼와 달리 세션당 또는 쿼리별 프라이빗 메모리 공간에 할당됩니다. 적절한 work_mem 크기를 설정하면 이러한 작업의 효율성을 크게 개선하고 디스크에 임시 데이터를 쓸 필요성을 줄일 수 있습니다.

핵심 사항

  • 프라이빗 연결 메모리: work_mem 각 데이터베이스 세션에서 사용하는 프라이빗 메모리의 일부입니다. 이 메모리는 사용하는 공유 메모리 영역 shared_buffers 과 다릅니다.
  • 쿼리별 사용: 모든 세션 또는 쿼리에서 사용하는 work_mem것은 아닙니다. SELECT 1 같은 간단한 쿼리는 work_mem이 필요할 가능성이 낮습니다. 복잡한 쿼리에서 정렬이나 해시 작업을 수행할 때 하나 또는 여러 work_mem 청크를 소모할 수 있습니다.
  • 병렬 작업: 여러 병렬 백 엔드에 걸쳐 있는 쿼리의 경우 각 백 엔드가 하나 또는 여러 work_mem 청크를 사용할 수 있습니다.

work_mem 모니터링 및 조정

주로 정렬 또는 해시 작업과 관련된 쿼리 실행 시간이 느린 경우 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정 work_mem 해야 합니다. Azure Portal에서 사용할 수 있는 도구를 사용하여 성능을 모니터링하는 방법은 다음과 같습니다.

세분화된 조정

매개 변수를 work_mem 관리하는 동안 전역 값을 설정하기보다는 세분화된 조정 방법을 채택하는 것이 더 효율적입니다. 이 방법을 사용하면 프로세스 및 사용자의 특정 요구 사항에 따라 신중하게 메모리를 할당할 수 있습니다. 또한 메모리 부족 문제가 발생할 위험을 최소화합니다. 다음은 이를 실행하는 방법입니다.

  • 사용자 수준: 특정 사용자가 주로 메모리 집약적인 집계 또는 보고 작업에 관련된 경우 해당 사용자의 값을 사용자 지정하는 것이 work_mem 좋습니다. 명령을 ALTER ROLE 사용하여 사용자 작업의 성능을 향상시킵니다.

  • 함수/프로시저 수준: 특정 함수 또는 프로시저가 상당한 임시 파일을 생성하는 경우 특정 함수 또는 프로시저 수준에서 값을 늘리는 work_mem 것이 도움이 될 수 있습니다. ALTER FUNCTION 또는 ALTER PROCEDURE 명령을 사용하여 특히 이러한 작업에 더 많은 메모리를 할당합니다.

  • 데이터베이스 수준: 특정 데이터베이스만 높은 수의 임시 파일을 생성하는 경우 데이터베이스 수준에서 변경 work_mem 합니다.

  • 전역 수준: 시스템을 분석한 결과 대부분의 쿼리가 작은 임시 파일을 생성하는 반면, 소수의 쿼리만 큰 파일을 만드는 경우 전역적으로 값을 늘리는 work_mem 것이 좋습니다. 이 작업을 통해 대부분의 쿼리가 메모리에서 처리할 수 있으므로 디스크 기반 작업을 방지하고 효율성을 향상시킬 수 있습니다. 그러나 항상 주의해야 하며 서버의 메모리 사용률을 모니터링하여 증가된 work_mem 값을 처리할 수 있는지 확인합니다.

정렬 작업에 대한 최소 work_mem 값 결정

특정 쿼리, 특히 정렬 프로세스 중에 임시 디스크 파일을 생성하는 최소 work_mem 값을 찾으려면 먼저 쿼리 실행 중에 생성된 임시 파일 크기를 고려합니다. 예를 들어 쿼리가 20MB 임시 파일을 생성하는 경우:

  1. psql 또는 선호하는 PostgreSQL 클라이언트를 사용하여 데이터베이스에 연결합니다.
  2. 메모리에서 처리할 때 추가 헤더를 고려하도록 초기 work_mem 값을 20MB보다 약간 높게 설정합니다. 다음과 같은 SET work_mem TO '25MB'명령을 사용합니다.
  3. 동일한 세션에서 문제가 있는 쿼리에 대해 EXPLAIN ANALYZE를 실행합니다.
  4. "Sort Method: quicksort Memory: xkB"에 대한 출력을 검토합니다. 만약 "external merge Disk: xkB"가 표시되면, work_mem 값을 점진적으로 올리고 "quicksort Memory"가 나타날 때까지 다시 테스트합니다. 쿼리가 현재 메모리에서 작동 중임을 나타내는 신호로 "quicksort Memory"가 표시됩니다.
  5. 이 메서드를 통해 값을 확인한 후에는 운영 요구 사항에 맞게 전역적으로 또는 보다 세부적인 수준에서 적용할 수 있습니다(앞에서 설명한 대로).

autovacuum_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 각 자동 진공 작업자 프로세스에서 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 -1
허용되는 값 -1-2097151
매개 변수 형식 dynamic
문서 autovacuum_work_mem

동적_공유_메모리_타입

특성 가치
카테고리 리소스 사용량/메모리
Description 사용되는 동적 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 posix
허용되는 값 posix
매개 변수 형식 읽기 전용
문서 동적_공유_메모리_타입

해시 메모리 곱셈기 (hash_mem_multiplier)

특성 가치
카테고리 리소스 사용량/메모리
Description 해시 테이블에 사용할 work_mem의 배수입니다.
데이터 형식 numeric
기본값 1
허용되는 값 1-1000
매개 변수 형식 dynamic
문서 hash_mem_multiplier

huge_pages

특성 가치
카테고리 리소스 사용량/메모리
Description 거대한 메모리 페이지를 사용하거나 사용하지 않도록 설정합니다. 이 설정은 vCore가 4개 미만인 서버에는 적용되지 않습니다.
데이터 형식 enumeration
기본값 try
허용되는 값 on,off,try
매개 변수 형식 정적
문서 huge_pages

Description

거대한 페이지는 더 큰 블록에서 메모리를 관리할 수 있는 기능입니다. 일반적으로 표준 4KB 페이지와 달리 최대 2MB의 블록을 관리할 수 있습니다.

거대한 페이지를 사용하면 CPU를 효과적으로 오프로드하는 성능 이점을 제공할 수 있습니다.

  • TLB(변환 색인 버퍼) 누락이 줄어드는 등 메모리 관리 작업과 관련된 오버헤드가 감소합니다.
  • 메모리 관리에 필요한 시간을 단축합니다.

특히 PostgreSQL에서는 공유 메모리 영역에 대해서만 거대한 페이지를 사용할 수 있습니다. 공유 메모리 영역의 상당 부분이 공유 버퍼에 할당됩니다.

또 다른 장점은 거대한 페이지가 공유 메모리 영역을 디스크로 교환하지 못하게 하여 성능을 더욱 안정화한다는 것입니다.

Recommendations

  • 메모리 리소스가 많은 서버의 경우 거대한 페이지를 사용하지 않도록 설정하지 마십시오. 거대한 페이지를 사용하지 않도록 설정하면 성능이 저하됩니다.
  • 대규모 페이지를 지원하지 않는 더 작은 서버로 시작하지만, 대규모 페이지를 지원하는 서버로 업그레이드할 계획이 있는 경우, 원활한 전환과 최적의 성능을 위해 huge_pages 설정을 TRY로 유지합니다.

Azure 관련 메모

vCore가 4개 이상인 서버의 경우 기본 운영 체제에서 거대한 페이지가 자동으로 할당됩니다. vCore가 4개 미만인 서버에서는 이 기능을 사용할 수 없습니다. 공유 메모리 설정이 변경되거나 shared_buffers과 같은 세부 사항이 변경되면 대용량 페이지 수가 자동으로 조정됩니다.

logical_decoding_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 논리 디코딩에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 65536
허용되는 값 64-2147483647
매개 변수 형식 dynamic
문서 logical_decoding_work_mem

maintenance_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, 인덱스 만들기와 같은 유지 관리 작업에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 1024-2097151
매개 변수 형식 dynamic
문서 maintenance_work_mem

Description

maintenance_work_mem 는 PostgreSQL의 구성 매개 변수입니다. 유지 관리 작업에 할당된 메모리 양(예: VACUUM, CREATE INDEX및 ALTER TABLE)을 제어합니다. 쿼리 작업에 대한 메모리 할당에 영향을 주는 것과 달리 work_mem데이터베이스 구조를 유지 관리하고 최적화하는 작업을 위해 예약되어 있습니다 maintenance_work_mem .

! [참고] 지나치게 공격적인 값으로 설정 maintenance_work_mem 하면 시스템에서 메모리 부족 오류가 주기적으로 발생할 수 있습니다. 이 매개 변수를 변경하기 전에 서버에서 사용할 수 있는 메모리 양과 앞에서 설명한 작업에 메모리를 할당할 수 있는 동시 작업 수를 이해하는 것이 매우 중요합니다.

핵심 사항

  • 진공 메모리 한도: maintenance_work_mem를 늘려 데드 튜플의 정리 속도를 높이고자 한다면, VACUUM에 데드 튜플 식별자를 수집하는 데 기본적으로 제한이 내재되어 있다는 점을 유의하세요. 이 프로세스에는 최대 1GB의 메모리만 사용할 수 있습니다.
  • 자동 진공을 위한 메모리 분리: 자동 진공 작업에서 독립적으로 사용하는 메모리를 제어하는 설정을 사용할 autovacuum_work_mem 수 있습니다. 이 설정은 .의 하위 집합으로 작동합니다 maintenance_work_mem. 다른 유지 관리 작업 및 데이터 정의 작업에 대한 메모리 할당에 영향을 주지 않고 자동 진공에서 사용하는 메모리 양을 결정할 수 있습니다.

Azure 관련 메모

maintenance_work_mem 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 maintenance_work_mem 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 maintenance_work_mem 값에 따라 매개 변수 값도 조정해야 합니다.

maintenance_work_mem 값을 계산하는 데 사용되는 수식은 (long)(82.5 * ln(memoryGiB) + 40) * 1024입니다.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 maintenance_work_mem
2GiB 99,328 KiB
4GiB 157,696KiB
8GiB 216,064KiB
16GiB 274,432 KiB
32GiB 332,800KiB
48GiB 367,616 KiB
64GiB 392,192KiB
80GiB 410,624KiB
128GiB 450,560KiB
160GiB 468,992 KiB
192GiB 484,352 KiB
256GiB 508,928 KiB
384GiB 542,720 KiB
432GiB 552,960KiB
672GiB 590,848 KiB

max_prepared_transactions

특성 가치
카테고리 리소스 사용량/메모리
Description 동시에 준비된 최대 트랜잭션 수를 설정합니다. 복제본 서버를 실행하는 경우 이 매개 변수를 기본 서버의 값 이상으로 설정해야 합니다.
데이터 형식 integer
기본값 0
허용되는 값 0-262143
매개 변수 형식 정적
문서 max_prepared_transactions

max_stack_depth

특성 가치
카테고리 리소스 사용량/메모리
Description 최대 스택 깊이(킬로바이트)를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 2048
매개 변수 형식 읽기 전용
문서 max_stack_depth

공유 버퍼 (shared_buffers)

특성 가치
카테고리 리소스 사용량/메모리
Description 서버에서 사용하는 공유 메모리 버퍼 수를 설정합니다. 단위는 8kb입니다. 허용되는 값은 사용 가능한 메모리의 10% - 75% 범위 내에 있습니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 16-1073741823
매개 변수 형식 정적
문서 shared_buffers

Description

구성 매개 변수는 shared_buffers 데이터를 버퍼링하기 위해 PostgreSQL 데이터베이스에 할당된 시스템 메모리 양을 결정합니다. 모든 데이터베이스 프로세스에서 액세스할 수 있는 중앙 집중식 메모리 풀 역할을 합니다.

데이터가 필요한 경우 데이터베이스 프로세스는 먼저 공유 버퍼를 확인합니다. 필요한 데이터가 있는 경우 빠르게 검색되고 시간이 많이 걸리는 디스크 읽기를 무시합니다. 공유 버퍼는 데이터베이스 프로세스와 디스크 간의 중개자 역할을 하며 필요한 I/O 작업의 수를 효과적으로 줄입니다.

Azure 관련 메모

shared_buffers 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 서버 매개 변수에 대한 기본값에 shared_buffers 영향을 주지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 shared_buffers 값에 따라 매개 변수 값도 조정해야 합니다.

최대 2GiB의 메모리가 있는 가상 머신의 경우 값을 shared_buffers 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 16384.

2GiB를 초과하는 가상 머신의 shared_buffers 경우 값을 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 32768.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 공유 버퍼 (shared_buffers)
2GiB 32768
4GiB 131072
8GiB 262144
16GiB 524288
32GiB 1048576
48GiB 1572864
64GiB 2097152
80GiB 2621440
128GiB 4194304
160GiB 5242880
192GiB 6291456
256GiB 8388608
384GiB 12582912
432GiB 14155776
672GiB 22020096

공유_메모리_유형

특성 가치
카테고리 리소스 사용량/메모리
Description 기본 공유 메모리 영역에 사용되는 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 mmap
허용되는 값 mmap
매개 변수 형식 읽기 전용
문서 공유_메모리_타입

임시 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 각 데이터베이스 세션에서 사용하는 최대 임시 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 100-1073741823
매개 변수 형식 dynamic
문서 temp_buffers

work_mem (워크 메모리)

특성 가치
카테고리 리소스 사용량/메모리
Description 임시 디스크 파일에 쓰기 전에 내부 정렬 작업 및 해시 테이블에서 사용할 메모리 양을 설정합니다.
데이터 형식 integer
기본값 4096
허용되는 값 4096-2097151
매개 변수 형식 dynamic
문서 work_mem

Description

PostgreSQL의 매개 변수는 work_mem 각 데이터베이스 세션의 프라이빗 메모리 영역 내에서 특정 내부 작업에 할당된 메모리 양을 제어합니다. 이러한 작업의 예로는 정렬 및 해시가 있습니다.

공유 메모리 영역에 work_mem 있는 공유 버퍼와 달리 세션당 또는 쿼리별 프라이빗 메모리 공간에 할당됩니다. 적절한 work_mem 크기를 설정하면 이러한 작업의 효율성을 크게 개선하고 디스크에 임시 데이터를 쓸 필요성을 줄일 수 있습니다.

핵심 사항

  • 프라이빗 연결 메모리: work_mem 각 데이터베이스 세션에서 사용하는 프라이빗 메모리의 일부입니다. 이 메모리는 사용하는 공유 메모리 영역 shared_buffers 과 다릅니다.
  • 쿼리별 사용: 모든 세션 또는 쿼리에서 사용하는 work_mem것은 아닙니다. SELECT 1 같은 간단한 쿼리는 work_mem이 필요할 가능성이 낮습니다. 복잡한 쿼리에서 정렬이나 해시 작업을 수행할 때 하나 또는 여러 work_mem 청크를 소모할 수 있습니다.
  • 병렬 작업: 여러 병렬 백 엔드에 걸쳐 있는 쿼리의 경우 각 백 엔드가 하나 또는 여러 work_mem 청크를 사용할 수 있습니다.

work_mem 모니터링 및 조정

주로 정렬 또는 해시 작업과 관련된 쿼리 실행 시간이 느린 경우 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정 work_mem 해야 합니다. Azure Portal에서 사용할 수 있는 도구를 사용하여 성능을 모니터링하는 방법은 다음과 같습니다.

세분화된 조정

매개 변수를 work_mem 관리하는 동안 전역 값을 설정하기보다는 세분화된 조정 방법을 채택하는 것이 더 효율적입니다. 이 방법을 사용하면 프로세스 및 사용자의 특정 요구 사항에 따라 신중하게 메모리를 할당할 수 있습니다. 또한 메모리 부족 문제가 발생할 위험을 최소화합니다. 다음은 이를 실행하는 방법입니다.

  • 사용자 수준: 특정 사용자가 주로 메모리 집약적인 집계 또는 보고 작업에 관련된 경우 해당 사용자의 값을 사용자 지정하는 것이 work_mem 좋습니다. 명령을 ALTER ROLE 사용하여 사용자 작업의 성능을 향상시킵니다.

  • 함수/프로시저 수준: 특정 함수 또는 프로시저가 상당한 임시 파일을 생성하는 경우 특정 함수 또는 프로시저 수준에서 값을 늘리는 work_mem 것이 도움이 될 수 있습니다. ALTER FUNCTION 또는 ALTER PROCEDURE 명령을 사용하여 특히 이러한 작업에 더 많은 메모리를 할당합니다.

  • 데이터베이스 수준: 특정 데이터베이스만 높은 수의 임시 파일을 생성하는 경우 데이터베이스 수준에서 변경 work_mem 합니다.

  • 전역 수준: 시스템을 분석한 결과 대부분의 쿼리가 작은 임시 파일을 생성하는 반면, 소수의 쿼리만 큰 파일을 만드는 경우 전역적으로 값을 늘리는 work_mem 것이 좋습니다. 이 작업을 통해 대부분의 쿼리가 메모리에서 처리할 수 있으므로 디스크 기반 작업을 방지하고 효율성을 향상시킬 수 있습니다. 그러나 항상 주의해야 하며 서버의 메모리 사용률을 모니터링하여 증가된 work_mem 값을 처리할 수 있는지 확인합니다.

정렬 작업에 대한 최소 work_mem 값 결정

특정 쿼리, 특히 정렬 프로세스 중에 임시 디스크 파일을 생성하는 최소 work_mem 값을 찾으려면 먼저 쿼리 실행 중에 생성된 임시 파일 크기를 고려합니다. 예를 들어 쿼리가 20MB 임시 파일을 생성하는 경우:

  1. psql 또는 선호하는 PostgreSQL 클라이언트를 사용하여 데이터베이스에 연결합니다.
  2. 메모리에서 처리할 때 추가 헤더를 고려하도록 초기 work_mem 값을 20MB보다 약간 높게 설정합니다. 다음과 같은 SET work_mem TO '25MB'명령을 사용합니다.
  3. 동일한 세션에서 문제가 있는 쿼리에 대해 EXPLAIN ANALYZE를 실행합니다.
  4. "Sort Method: quicksort Memory: xkB"에 대한 출력을 검토합니다. 만약 "external merge Disk: xkB"가 표시되면, work_mem 값을 점진적으로 올리고 "quicksort Memory"가 나타날 때까지 다시 테스트합니다. 쿼리가 현재 메모리에서 작동 중임을 나타내는 신호로 "quicksort Memory"가 표시됩니다.
  5. 이 메서드를 통해 값을 확인한 후에는 운영 요구 사항에 맞게 전역적으로 또는 보다 세부적인 수준에서 적용할 수 있습니다(앞에서 설명한 대로).

autovacuum_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 각 자동 진공 작업자 프로세스에서 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 -1
허용되는 값 -1-2097151
매개 변수 형식 dynamic
문서 autovacuum_work_mem

동적_공유_메모리_타입

특성 가치
카테고리 리소스 사용량/메모리
Description 사용되는 동적 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 posix
허용되는 값 posix
매개 변수 형식 읽기 전용
문서 동적_공유_메모리_타입

해시 메모리 곱셈기 (hash_mem_multiplier)

특성 가치
카테고리 리소스 사용량/메모리
Description 해시 테이블에 사용할 work_mem의 배수입니다.
데이터 형식 numeric
기본값 1
허용되는 값 1-1000
매개 변수 형식 dynamic
문서 hash_mem_multiplier

huge_pages

특성 가치
카테고리 리소스 사용량/메모리
Description 거대한 메모리 페이지를 사용하거나 사용하지 않도록 설정합니다. 이 설정은 vCore가 4개 미만인 서버에는 적용되지 않습니다.
데이터 형식 enumeration
기본값 try
허용되는 값 on,off,try
매개 변수 형식 정적
문서 huge_pages

Description

거대한 페이지는 더 큰 블록에서 메모리를 관리할 수 있는 기능입니다. 일반적으로 표준 4KB 페이지와 달리 최대 2MB의 블록을 관리할 수 있습니다.

거대한 페이지를 사용하면 CPU를 효과적으로 오프로드하는 성능 이점을 제공할 수 있습니다.

  • TLB(변환 색인 버퍼) 누락이 줄어드는 등 메모리 관리 작업과 관련된 오버헤드가 감소합니다.
  • 메모리 관리에 필요한 시간을 단축합니다.

특히 PostgreSQL에서는 공유 메모리 영역에 대해서만 거대한 페이지를 사용할 수 있습니다. 공유 메모리 영역의 상당 부분이 공유 버퍼에 할당됩니다.

또 다른 장점은 거대한 페이지가 공유 메모리 영역을 디스크로 교환하지 못하게 하여 성능을 더욱 안정화한다는 것입니다.

Recommendations

  • 메모리 리소스가 많은 서버의 경우 거대한 페이지를 사용하지 않도록 설정하지 마십시오. 거대한 페이지를 사용하지 않도록 설정하면 성능이 저하됩니다.
  • 대규모 페이지를 지원하지 않는 더 작은 서버로 시작하지만, 대규모 페이지를 지원하는 서버로 업그레이드할 계획이 있는 경우, 원활한 전환과 최적의 성능을 위해 huge_pages 설정을 TRY로 유지합니다.

Azure 관련 메모

vCore가 4개 이상인 서버의 경우 기본 운영 체제에서 거대한 페이지가 자동으로 할당됩니다. vCore가 4개 미만인 서버에서는 이 기능을 사용할 수 없습니다. 공유 메모리 설정이 변경되거나 shared_buffers과 같은 세부 사항이 변경되면 대용량 페이지 수가 자동으로 조정됩니다.

maintenance_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, 인덱스 만들기와 같은 유지 관리 작업에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 1024-2097151
매개 변수 형식 dynamic
문서 maintenance_work_mem

Description

maintenance_work_mem 는 PostgreSQL의 구성 매개 변수입니다. 유지 관리 작업에 할당된 메모리 양(예: VACUUM, CREATE INDEX및 ALTER TABLE)을 제어합니다. 쿼리 작업에 대한 메모리 할당에 영향을 주는 것과 달리 work_mem데이터베이스 구조를 유지 관리하고 최적화하는 작업을 위해 예약되어 있습니다 maintenance_work_mem .

! [참고] 지나치게 공격적인 값으로 설정 maintenance_work_mem 하면 시스템에서 메모리 부족 오류가 주기적으로 발생할 수 있습니다. 이 매개 변수를 변경하기 전에 서버에서 사용할 수 있는 메모리 양과 앞에서 설명한 작업에 메모리를 할당할 수 있는 동시 작업 수를 이해하는 것이 매우 중요합니다.

핵심 사항

  • 진공 메모리 한도: maintenance_work_mem를 늘려 데드 튜플의 정리 속도를 높이고자 한다면, VACUUM에 데드 튜플 식별자를 수집하는 데 기본적으로 제한이 내재되어 있다는 점을 유의하세요. 이 프로세스에는 최대 1GB의 메모리만 사용할 수 있습니다.
  • 자동 진공을 위한 메모리 분리: 자동 진공 작업에서 독립적으로 사용하는 메모리를 제어하는 설정을 사용할 autovacuum_work_mem 수 있습니다. 이 설정은 .의 하위 집합으로 작동합니다 maintenance_work_mem. 다른 유지 관리 작업 및 데이터 정의 작업에 대한 메모리 할당에 영향을 주지 않고 자동 진공에서 사용하는 메모리 양을 결정할 수 있습니다.

Azure 관련 메모

maintenance_work_mem 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 maintenance_work_mem 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 maintenance_work_mem 값에 따라 매개 변수 값도 조정해야 합니다.

maintenance_work_mem 값을 계산하는 데 사용되는 수식은 (long)(82.5 * ln(memoryGiB) + 40) * 1024입니다.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 maintenance_work_mem
2GiB 99,328 KiB
4GiB 157,696KiB
8GiB 216,064KiB
16GiB 274,432 KiB
32GiB 332,800KiB
48GiB 367,616 KiB
64GiB 392,192KiB
80GiB 410,624KiB
128GiB 450,560KiB
160GiB 468,992 KiB
192GiB 484,352 KiB
256GiB 508,928 KiB
384GiB 542,720 KiB
432GiB 552,960KiB
672GiB 590,848 KiB

max_prepared_transactions

특성 가치
카테고리 리소스 사용량/메모리
Description 동시에 준비된 최대 트랜잭션 수를 설정합니다. 복제본 서버를 실행하는 경우 이 매개 변수를 기본 서버의 값 이상으로 설정해야 합니다.
데이터 형식 integer
기본값 0
허용되는 값 0-262143
매개 변수 형식 정적
문서 max_prepared_transactions

max_stack_depth

특성 가치
카테고리 리소스 사용량/메모리
Description 최대 스택 깊이(킬로바이트)를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 2048
매개 변수 형식 읽기 전용
문서 max_stack_depth

공유 버퍼 (shared_buffers)

특성 가치
카테고리 리소스 사용량/메모리
Description 서버에서 사용하는 공유 메모리 버퍼 수를 설정합니다. 단위는 8kb입니다. 허용되는 값은 사용 가능한 메모리의 10% - 75% 범위 내에 있습니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 16-1073741823
매개 변수 형식 정적
문서 shared_buffers

Description

구성 매개 변수는 shared_buffers 데이터를 버퍼링하기 위해 PostgreSQL 데이터베이스에 할당된 시스템 메모리 양을 결정합니다. 모든 데이터베이스 프로세스에서 액세스할 수 있는 중앙 집중식 메모리 풀 역할을 합니다.

데이터가 필요한 경우 데이터베이스 프로세스는 먼저 공유 버퍼를 확인합니다. 필요한 데이터가 있는 경우 빠르게 검색되고 시간이 많이 걸리는 디스크 읽기를 무시합니다. 공유 버퍼는 데이터베이스 프로세스와 디스크 간의 중개자 역할을 하며 필요한 I/O 작업의 수를 효과적으로 줄입니다.

Azure 관련 메모

shared_buffers 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 서버 매개 변수에 대한 기본값에 shared_buffers 영향을 주지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 shared_buffers 값에 따라 매개 변수 값도 조정해야 합니다.

최대 2GiB의 메모리가 있는 가상 머신의 경우 값을 shared_buffers 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 16384.

2GiB를 초과하는 가상 머신의 shared_buffers 경우 값을 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 32768.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 공유 버퍼 (shared_buffers)
2GiB 32768
4GiB 131072
8GiB 262144
16GiB 524288
32GiB 1048576
48GiB 1572864
64GiB 2097152
80GiB 2621440
128GiB 4194304
160GiB 5242880
192GiB 6291456
256GiB 8388608
384GiB 12582912
432GiB 14155776
672GiB 22020096

공유_메모리_유형

특성 가치
카테고리 리소스 사용량/메모리
Description 기본 공유 메모리 영역에 사용되는 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 mmap
허용되는 값 mmap
매개 변수 형식 읽기 전용
문서 공유_메모리_타입

임시 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 각 데이터베이스 세션에서 사용하는 최대 임시 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 100-1073741823
매개 변수 형식 dynamic
문서 temp_buffers

work_mem (워크 메모리)

특성 가치
카테고리 리소스 사용량/메모리
Description 임시 디스크 파일에 쓰기 전에 내부 정렬 작업 및 해시 테이블에서 사용할 메모리 양을 설정합니다.
데이터 형식 integer
기본값 4096
허용되는 값 4096-2097151
매개 변수 형식 dynamic
문서 work_mem

Description

PostgreSQL의 매개 변수는 work_mem 각 데이터베이스 세션의 프라이빗 메모리 영역 내에서 특정 내부 작업에 할당된 메모리 양을 제어합니다. 이러한 작업의 예로는 정렬 및 해시가 있습니다.

공유 메모리 영역에 work_mem 있는 공유 버퍼와 달리 세션당 또는 쿼리별 프라이빗 메모리 공간에 할당됩니다. 적절한 work_mem 크기를 설정하면 이러한 작업의 효율성을 크게 개선하고 디스크에 임시 데이터를 쓸 필요성을 줄일 수 있습니다.

핵심 사항

  • 프라이빗 연결 메모리: work_mem 각 데이터베이스 세션에서 사용하는 프라이빗 메모리의 일부입니다. 이 메모리는 사용하는 공유 메모리 영역 shared_buffers 과 다릅니다.
  • 쿼리별 사용: 모든 세션 또는 쿼리에서 사용하는 work_mem것은 아닙니다. SELECT 1 같은 간단한 쿼리는 work_mem이 필요할 가능성이 낮습니다. 복잡한 쿼리에서 정렬이나 해시 작업을 수행할 때 하나 또는 여러 work_mem 청크를 소모할 수 있습니다.
  • 병렬 작업: 여러 병렬 백 엔드에 걸쳐 있는 쿼리의 경우 각 백 엔드가 하나 또는 여러 work_mem 청크를 사용할 수 있습니다.

work_mem 모니터링 및 조정

주로 정렬 또는 해시 작업과 관련된 쿼리 실행 시간이 느린 경우 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정 work_mem 해야 합니다. Azure Portal에서 사용할 수 있는 도구를 사용하여 성능을 모니터링하는 방법은 다음과 같습니다.

세분화된 조정

매개 변수를 work_mem 관리하는 동안 전역 값을 설정하기보다는 세분화된 조정 방법을 채택하는 것이 더 효율적입니다. 이 방법을 사용하면 프로세스 및 사용자의 특정 요구 사항에 따라 신중하게 메모리를 할당할 수 있습니다. 또한 메모리 부족 문제가 발생할 위험을 최소화합니다. 다음은 이를 실행하는 방법입니다.

  • 사용자 수준: 특정 사용자가 주로 메모리 집약적인 집계 또는 보고 작업에 관련된 경우 해당 사용자의 값을 사용자 지정하는 것이 work_mem 좋습니다. 명령을 ALTER ROLE 사용하여 사용자 작업의 성능을 향상시킵니다.

  • 함수/프로시저 수준: 특정 함수 또는 프로시저가 상당한 임시 파일을 생성하는 경우 특정 함수 또는 프로시저 수준에서 값을 늘리는 work_mem 것이 도움이 될 수 있습니다. ALTER FUNCTION 또는 ALTER PROCEDURE 명령을 사용하여 특히 이러한 작업에 더 많은 메모리를 할당합니다.

  • 데이터베이스 수준: 특정 데이터베이스만 높은 수의 임시 파일을 생성하는 경우 데이터베이스 수준에서 변경 work_mem 합니다.

  • 전역 수준: 시스템을 분석한 결과 대부분의 쿼리가 작은 임시 파일을 생성하는 반면, 소수의 쿼리만 큰 파일을 만드는 경우 전역적으로 값을 늘리는 work_mem 것이 좋습니다. 이 작업을 통해 대부분의 쿼리가 메모리에서 처리할 수 있으므로 디스크 기반 작업을 방지하고 효율성을 향상시킬 수 있습니다. 그러나 항상 주의해야 하며 서버의 메모리 사용률을 모니터링하여 증가된 work_mem 값을 처리할 수 있는지 확인합니다.

정렬 작업에 대한 최소 work_mem 값 결정

특정 쿼리, 특히 정렬 프로세스 중에 임시 디스크 파일을 생성하는 최소 work_mem 값을 찾으려면 먼저 쿼리 실행 중에 생성된 임시 파일 크기를 고려합니다. 예를 들어 쿼리가 20MB 임시 파일을 생성하는 경우:

  1. psql 또는 선호하는 PostgreSQL 클라이언트를 사용하여 데이터베이스에 연결합니다.
  2. 메모리에서 처리할 때 추가 헤더를 고려하도록 초기 work_mem 값을 20MB보다 약간 높게 설정합니다. 다음과 같은 SET work_mem TO '25MB'명령을 사용합니다.
  3. 동일한 세션에서 문제가 있는 쿼리에 대해 EXPLAIN ANALYZE를 실행합니다.
  4. "Sort Method: quicksort Memory: xkB"에 대한 출력을 검토합니다. 만약 "external merge Disk: xkB"가 표시되면, work_mem 값을 점진적으로 올리고 "quicksort Memory"가 나타날 때까지 다시 테스트합니다. 쿼리가 현재 메모리에서 작동 중임을 나타내는 신호로 "quicksort Memory"가 표시됩니다.
  5. 이 메서드를 통해 값을 확인한 후에는 운영 요구 사항에 맞게 전역적으로 또는 보다 세부적인 수준에서 적용할 수 있습니다(앞에서 설명한 대로).

autovacuum_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description 각 자동 진공 작업자 프로세스에서 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 -1
허용되는 값 -1-2097151
매개 변수 형식 dynamic
문서 autovacuum_work_mem

동적_공유_메모리_타입

특성 가치
카테고리 리소스 사용량/메모리
Description 사용되는 동적 공유 메모리 구현을 선택합니다.
데이터 형식 enumeration
기본값 posix
허용되는 값 posix
매개 변수 형식 읽기 전용
문서 동적_공유_메모리_타입

huge_pages

특성 가치
카테고리 리소스 사용량/메모리
Description 거대한 메모리 페이지를 사용하거나 사용하지 않도록 설정합니다. 이 설정은 vCore가 4개 미만인 서버에는 적용되지 않습니다.
데이터 형식 enumeration
기본값 try
허용되는 값 on,off,try
매개 변수 형식 정적
문서 huge_pages

Description

거대한 페이지는 더 큰 블록에서 메모리를 관리할 수 있는 기능입니다. 일반적으로 표준 4KB 페이지와 달리 최대 2MB의 블록을 관리할 수 있습니다.

거대한 페이지를 사용하면 CPU를 효과적으로 오프로드하는 성능 이점을 제공할 수 있습니다.

  • TLB(변환 색인 버퍼) 누락이 줄어드는 등 메모리 관리 작업과 관련된 오버헤드가 감소합니다.
  • 메모리 관리에 필요한 시간을 단축합니다.

특히 PostgreSQL에서는 공유 메모리 영역에 대해서만 거대한 페이지를 사용할 수 있습니다. 공유 메모리 영역의 상당 부분이 공유 버퍼에 할당됩니다.

또 다른 장점은 거대한 페이지가 공유 메모리 영역을 디스크로 교환하지 못하게 하여 성능을 더욱 안정화한다는 것입니다.

Recommendations

  • 메모리 리소스가 많은 서버의 경우 거대한 페이지를 사용하지 않도록 설정하지 마십시오. 거대한 페이지를 사용하지 않도록 설정하면 성능이 저하됩니다.
  • 대규모 페이지를 지원하지 않는 더 작은 서버로 시작하지만, 대규모 페이지를 지원하는 서버로 업그레이드할 계획이 있는 경우, 원활한 전환과 최적의 성능을 위해 huge_pages 설정을 TRY로 유지합니다.

Azure 관련 메모

vCore가 4개 이상인 서버의 경우 기본 운영 체제에서 거대한 페이지가 자동으로 할당됩니다. vCore가 4개 미만인 서버에서는 이 기능을 사용할 수 없습니다. 공유 메모리 설정이 변경되거나 shared_buffers과 같은 세부 사항이 변경되면 대용량 페이지 수가 자동으로 조정됩니다.

maintenance_work_mem

특성 가치
카테고리 리소스 사용량/메모리
Description VACUUM, 인덱스 만들기와 같은 유지 관리 작업에 사용할 최대 메모리를 설정합니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 1024-2097151
매개 변수 형식 dynamic
문서 maintenance_work_mem

Description

maintenance_work_mem 는 PostgreSQL의 구성 매개 변수입니다. 유지 관리 작업에 할당된 메모리 양(예: VACUUM, CREATE INDEX및 ALTER TABLE)을 제어합니다. 쿼리 작업에 대한 메모리 할당에 영향을 주는 것과 달리 work_mem데이터베이스 구조를 유지 관리하고 최적화하는 작업을 위해 예약되어 있습니다 maintenance_work_mem .

! [참고] 지나치게 공격적인 값으로 설정 maintenance_work_mem 하면 시스템에서 메모리 부족 오류가 주기적으로 발생할 수 있습니다. 이 매개 변수를 변경하기 전에 서버에서 사용할 수 있는 메모리 양과 앞에서 설명한 작업에 메모리를 할당할 수 있는 동시 작업 수를 이해하는 것이 매우 중요합니다.

핵심 사항

  • 진공 메모리 한도: maintenance_work_mem를 늘려 데드 튜플의 정리 속도를 높이고자 한다면, VACUUM에 데드 튜플 식별자를 수집하는 데 기본적으로 제한이 내재되어 있다는 점을 유의하세요. 이 프로세스에는 최대 1GB의 메모리만 사용할 수 있습니다.
  • 자동 진공을 위한 메모리 분리: 자동 진공 작업에서 독립적으로 사용하는 메모리를 제어하는 설정을 사용할 autovacuum_work_mem 수 있습니다. 이 설정은 .의 하위 집합으로 작동합니다 maintenance_work_mem. 다른 유지 관리 작업 및 데이터 정의 작업에 대한 메모리 할당에 영향을 주지 않고 자동 진공에서 사용하는 메모리 양을 결정할 수 있습니다.

Azure 관련 메모

maintenance_work_mem 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 maintenance_work_mem 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 maintenance_work_mem 값에 따라 매개 변수 값도 조정해야 합니다.

maintenance_work_mem 값을 계산하는 데 사용되는 수식은 (long)(82.5 * ln(memoryGiB) + 40) * 1024입니다.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 maintenance_work_mem
2GiB 99,328 KiB
4GiB 157,696KiB
8GiB 216,064KiB
16GiB 274,432 KiB
32GiB 332,800KiB
48GiB 367,616 KiB
64GiB 392,192KiB
80GiB 410,624KiB
128GiB 450,560KiB
160GiB 468,992 KiB
192GiB 484,352 KiB
256GiB 508,928 KiB
384GiB 542,720 KiB
432GiB 552,960KiB
672GiB 590,848 KiB

max_prepared_transactions

특성 가치
카테고리 리소스 사용량/메모리
Description 동시에 준비된 최대 트랜잭션 수를 설정합니다. 복제본 서버를 실행하는 경우 이 매개 변수를 기본 서버의 값 이상으로 설정해야 합니다.
데이터 형식 integer
기본값 0
허용되는 값 0-262143
매개 변수 형식 정적
문서 max_prepared_transactions

max_stack_depth

특성 가치
카테고리 리소스 사용량/메모리
Description 최대 스택 깊이(킬로바이트)를 설정합니다.
데이터 형식 integer
기본값 2048
허용되는 값 2048
매개 변수 형식 읽기 전용
문서 max_stack_depth

공유 버퍼 (shared_buffers)

특성 가치
카테고리 리소스 사용량/메모리
Description 서버에서 사용하는 공유 메모리 버퍼 수를 설정합니다. 단위는 8kb입니다. 허용되는 값은 사용 가능한 메모리의 10% - 75% 범위 내에 있습니다.
데이터 형식 integer
기본값 서버에 할당된 리소스(vCore, RAM 또는 디스크 공간)에 따라 달라집니다.
허용되는 값 16-1073741823
매개 변수 형식 정적
문서 shared_buffers

Description

구성 매개 변수는 shared_buffers 데이터를 버퍼링하기 위해 PostgreSQL 데이터베이스에 할당된 시스템 메모리 양을 결정합니다. 모든 데이터베이스 프로세스에서 액세스할 수 있는 중앙 집중식 메모리 풀 역할을 합니다.

데이터가 필요한 경우 데이터베이스 프로세스는 먼저 공유 버퍼를 확인합니다. 필요한 데이터가 있는 경우 빠르게 검색되고 시간이 많이 걸리는 디스크 읽기를 무시합니다. 공유 버퍼는 데이터베이스 프로세스와 디스크 간의 중개자 역할을 하며 필요한 I/O 작업의 수를 효과적으로 줄입니다.

Azure 관련 메모

shared_buffers 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 서버 매개 변수에 대한 기본값에 shared_buffers 영향을 주지 않습니다.

인스턴스에 할당된 제품을 변경할 때마다 다음 수식의 shared_buffers 값에 따라 매개 변수 값도 조정해야 합니다.

최대 2GiB의 메모리가 있는 가상 머신의 경우 값을 shared_buffers 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 16384.

2GiB를 초과하는 가상 머신의 shared_buffers 경우 값을 계산하는 데 사용되는 수식은 다음과 입니다 memoryGib * 32768.

이전 수식에 따라 다음 표에서는 프로비전된 메모리 양에 따라 이 서버 매개 변수가 설정되는 값을 나열합니다.

메모리 크기 공유 버퍼 (shared_buffers)
2GiB 32768
4GiB 131072
8GiB 262144
16GiB 524288
32GiB 1048576
48GiB 1572864
64GiB 2097152
80GiB 2621440
128GiB 4194304
160GiB 5242880
192GiB 6291456
256GiB 8388608
384GiB 12582912
432GiB 14155776
672GiB 22020096

임시 버퍼

특성 가치
카테고리 리소스 사용량/메모리
Description 각 데이터베이스 세션에서 사용하는 최대 임시 버퍼 수를 설정합니다.
데이터 형식 integer
기본값 1024
허용되는 값 100-1073741823
매개 변수 형식 dynamic
문서 temp_buffers

work_mem (워크 메모리)

특성 가치
카테고리 리소스 사용량/메모리
Description 임시 디스크 파일에 쓰기 전에 내부 정렬 작업 및 해시 테이블에서 사용할 메모리 양을 설정합니다.
데이터 형식 integer
기본값 4096
허용되는 값 4096-2097151
매개 변수 형식 dynamic
문서 work_mem

Description

PostgreSQL의 매개 변수는 work_mem 각 데이터베이스 세션의 프라이빗 메모리 영역 내에서 특정 내부 작업에 할당된 메모리 양을 제어합니다. 이러한 작업의 예로는 정렬 및 해시가 있습니다.

공유 메모리 영역에 work_mem 있는 공유 버퍼와 달리 세션당 또는 쿼리별 프라이빗 메모리 공간에 할당됩니다. 적절한 work_mem 크기를 설정하면 이러한 작업의 효율성을 크게 개선하고 디스크에 임시 데이터를 쓸 필요성을 줄일 수 있습니다.

핵심 사항

  • 프라이빗 연결 메모리: work_mem 각 데이터베이스 세션에서 사용하는 프라이빗 메모리의 일부입니다. 이 메모리는 사용하는 공유 메모리 영역 shared_buffers 과 다릅니다.
  • 쿼리별 사용: 모든 세션 또는 쿼리에서 사용하는 work_mem것은 아닙니다. SELECT 1 같은 간단한 쿼리는 work_mem이 필요할 가능성이 낮습니다. 복잡한 쿼리에서 정렬이나 해시 작업을 수행할 때 하나 또는 여러 work_mem 청크를 소모할 수 있습니다.
  • 병렬 작업: 여러 병렬 백 엔드에 걸쳐 있는 쿼리의 경우 각 백 엔드가 하나 또는 여러 work_mem 청크를 사용할 수 있습니다.

work_mem 모니터링 및 조정

주로 정렬 또는 해시 작업과 관련된 쿼리 실행 시간이 느린 경우 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정 work_mem 해야 합니다. Azure Portal에서 사용할 수 있는 도구를 사용하여 성능을 모니터링하는 방법은 다음과 같습니다.

세분화된 조정

매개 변수를 work_mem 관리하는 동안 전역 값을 설정하기보다는 세분화된 조정 방법을 채택하는 것이 더 효율적입니다. 이 방법을 사용하면 프로세스 및 사용자의 특정 요구 사항에 따라 신중하게 메모리를 할당할 수 있습니다. 또한 메모리 부족 문제가 발생할 위험을 최소화합니다. 다음은 이를 실행하는 방법입니다.

  • 사용자 수준: 특정 사용자가 주로 메모리 집약적인 집계 또는 보고 작업에 관련된 경우 해당 사용자의 값을 사용자 지정하는 것이 work_mem 좋습니다. 명령을 ALTER ROLE 사용하여 사용자 작업의 성능을 향상시킵니다.

  • 함수/프로시저 수준: 특정 함수 또는 프로시저가 상당한 임시 파일을 생성하는 경우 특정 함수 또는 프로시저 수준에서 값을 늘리는 work_mem 것이 도움이 될 수 있습니다. ALTER FUNCTION 또는 ALTER PROCEDURE 명령을 사용하여 특히 이러한 작업에 더 많은 메모리를 할당합니다.

  • 데이터베이스 수준: 특정 데이터베이스만 높은 수의 임시 파일을 생성하는 경우 데이터베이스 수준에서 변경 work_mem 합니다.

  • 전역 수준: 시스템을 분석한 결과 대부분의 쿼리가 작은 임시 파일을 생성하는 반면, 소수의 쿼리만 큰 파일을 만드는 경우 전역적으로 값을 늘리는 work_mem 것이 좋습니다. 이 작업을 통해 대부분의 쿼리가 메모리에서 처리할 수 있으므로 디스크 기반 작업을 방지하고 효율성을 향상시킬 수 있습니다. 그러나 항상 주의해야 하며 서버의 메모리 사용률을 모니터링하여 증가된 work_mem 값을 처리할 수 있는지 확인합니다.

정렬 작업에 대한 최소 work_mem 값 결정

특정 쿼리, 특히 정렬 프로세스 중에 임시 디스크 파일을 생성하는 최소 work_mem 값을 찾으려면 먼저 쿼리 실행 중에 생성된 임시 파일 크기를 고려합니다. 예를 들어 쿼리가 20MB 임시 파일을 생성하는 경우:

  1. psql 또는 선호하는 PostgreSQL 클라이언트를 사용하여 데이터베이스에 연결합니다.
  2. 메모리에서 처리할 때 추가 헤더를 고려하도록 초기 work_mem 값을 20MB보다 약간 높게 설정합니다. 다음과 같은 SET work_mem TO '25MB'명령을 사용합니다.
  3. 동일한 세션에서 문제가 있는 쿼리에 대해 EXPLAIN ANALYZE를 실행합니다.
  4. "Sort Method: quicksort Memory: xkB"에 대한 출력을 검토합니다. 만약 "external merge Disk: xkB"가 표시되면, work_mem 값을 점진적으로 올리고 "quicksort Memory"가 나타날 때까지 다시 테스트합니다. 쿼리가 현재 메모리에서 작동 중임을 나타내는 신호로 "quicksort Memory"가 표시됩니다.
  5. 이 메서드를 통해 값을 확인한 후에는 운영 요구 사항에 맞게 전역적으로 또는 보다 세부적인 수준에서 적용할 수 있습니다(앞에서 설명한 대로).
  • Last updated on