13.6 핵심 메모리 파라미터

PostgreSQL 메모리 파라미터는 서로 얽혀 있습니다. 하나만 만져서는 효과가 부족하고, 잘못 묶으면 OOM으로 이어집니다. 그래서 1.4·5.2에서 나눠 본 내용을 여기서 운영 결정 관점으로 다시 묶습니다.

핵심 4파라미터

다른 보조:

시작 매트릭스 — 워크로드별

분석 워크로드는 세션 단위 SET LOCAL work_mem으로 큰 값을 쓰기를 권장합니다. 기본값은 작게 유지합니다.

work_mem 정확 계산

peak ≈ work_mem × N(operations) × N(connections) × (1 + parallel_workers_per_query)

→ 최악의 경우 64 × 3 × 200 × 3 = 약 115GB입니다(이론값). 실제로 모든 세션이 동시에 최대치를 쓰지는 않습니다.

운영 권장:

• work_mem은 작게 디폴트
• 무거운 쿼리는 세션 단위로 SET

-- 분석 세션
SET work_mem = '512MB';
SELECT ... ;
RESET work_mem;

shared_buffers 결정의 미묘

같은 RAM에서 shared_buffers를 키울지 work_mem을 키울지 저울질:

• 같은 데이터를 자주 읽음 → shared_buffers
• 동시 분석 쿼리가 많음 → work_mem (세션 단위 권장)

effective_cache_size — 옵티마이저 힌트

effective_cache_size = shared_buffers + OS page cache 추정

호스트 RAM의 50~75%가 출발. 옵티마이저가 인덱스 스캔 vs 시퀀셜을 비교할 때 참고합니다.

메모리를 실제로 할당하지는 않고 옵티마이저에 주는 힌트일 뿐입니다. 너무 작으면 옵티마이저가 인덱스 스캔 비용을 과대 추정합니다.

maintenance_work_mem — autovacuum과의 관계

autovacuum_work_mem = -1   -- = maintenance_work_mem

기본은 같이 묶임. autovacuum이 maintenance_work_mem을 다 차지하면 큰 인덱스 빌드 메모리가 부족.

ALTER SYSTEM SET maintenance_work_mem = '2GB';
ALTER SYSTEM SET autovacuum_work_mem = '256MB';   -- autovacuum 별도

autovacuum은 워커당 autovacuum_work_mem을 쓰므로 autovacuum_work_mem × autovacuum_max_workers만큼 차지합니다(256MB × 5 = 1.25GB).

wal_buffers

wal_buffers = -1   -- auto: shared_buffers의 1/32, max 16MB

대부분 그대로 둡니다. 커밋 TPS가 매우 높을 때만 32MB·64MB로 올립니다.

wal_buffers_full(pg_stat_wal)이 자주 증가하면 값을 키웁니다.

실전 튜닝 — 4단계

    flowchart TD
  S["시작값 선택<br/>(워크로드 매트릭스)"]
  M["측정<br/>(temp_files, evictions, swap)"]
  D{"문제?"}
  W["work_mem 증액<br/>(세션 단위 우선)"]
  SB["shared_buffers 증액"]
  MWM["maintenance_work_mem 증액"]
  END["완료"]

  S --> M --> D
  D -- "temp_files 많음" --> W --> M
  D -- "buffer evictions 많음" --> SB --> M
  D -- "VACUUM 느림" --> MWM --> M
  D -- "정상" --> END

  classDef step fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
  classDef done fill:#d1fae5,stroke:#047857,color:#064e3b
  class S,M,W,SB,MWM step
  class END,D done
  

진단 SQL

-- temp_file (work_mem 부족 신호)
SELECT datname,
       temp_files,
       pg_size_pretty(temp_bytes) AS temp_size
  FROM pg_stat_database
 WHERE datname = current_database();

-- shared_buffers evict (cache miss)
SELECT * FROM pg_stat_io WHERE op = 'evict';  -- PG 16+

-- wal_buffers 부족
SELECT wal_buffers_full FROM pg_stat_wal;

-- 현재 메모리 파라미터
SELECT name, setting, unit FROM pg_settings
 WHERE name IN ('shared_buffers','work_mem','effective_cache_size',
                'maintenance_work_mem','wal_buffers','temp_buffers');

클라우드 매니지드의 자동 튜닝

매니지드 환경에서는 OS·HW 권장 사항 일부가 적용되지 않습니다(THP·NUMA 등은 콘솔에서 못 만집니다). 인스턴스 크기 변경이 표준 튜닝 수단입니다.

운영 안티패턴

정리

핵심은 shared_buffers·effective_cache_size·work_mem·maintenance_work_mem 네 파라미터입니다. 시작점은 호스트 RAM의 25%, 50~75%, 16MB, 1GB이고, work_mem은 작게 두되 분석 쿼리만 세션 단위로 올립니다. shared_buffers를 50% 이상으로 잡으면 이중 캐싱으로 손해입니다.

• autovacuum_work_mem을 maintenance에서 분리하면 큰 인덱스 빌드 메모리 확보
• 변경은 하나씩 적용하고 측정, 클라우드 매니지드는 인스턴스 크기로 대신

이것으로 Part XIII 성능과 튜닝을 마칩니다.