PostgreSQL 메모리: shared_buffers와 work_mem 설정

소개

PostgreSQL 성능에서 메모리 설정은 핵심 요소다. 잘못된 값은 성능 저하나 메모리 부족을 초래한다. 이 글은 shared_buffers와 work_mem의 역할을 쉽게 설명하고, 실무에서 적용 가능한 계산법과 점검 절차를 제시한다. 처음 접하는 사람도 이해하기 쉽게 단계별로 정리한다.

shared_buffers란 무엇인가?

shared_buffers는 PostgreSQL 프로세스가 직접 사용하는 버퍼 캐시 크기다. 이 공간은 디스크에서 읽은 페이지를 보관해 재사용을 빠르게 한다. 운영체제의 파일시스템 캐시와 역할이 겹치므로 균형이 중요하다.

설정 원칙

• 전용 DB 서버라면 전체 메모리의 20~40%를 첫 시작점으로 고려
• 공유 호스팅이나 복합 용도 서버는 더 보수적으로 설정
• 큰 값을 무작정 늘리기보다는 모니터링과 성능 테스트가 우선

예시 설정

postgresql.conf에 직접 입력하거나 임시로 세션에서 변경 가능하다.

shared_buffers = 8GB
# 또는
ALTER SYSTEM SET shared_buffers = '8GB';
SELECT pg_reload_conf();

work_mem이란 무엇인가?

work_mem은 정렬(sort)과 해시 조인(hash join) 등 메모리 작업에 할당되는 최대 메모리다. 단위는 바이트, 키워드로는 per-operation, per-sort이다. 즉 하나의 쿼리가 여러 정렬 단계를 사용하면 각 단계에 work_mem이 할당된다.

설정 시 주의점

• work_mem은 동시 연결과 쿼리 복잡성에 따라 총 사용량이 급증할 수 있다
• 너무 작으면 디스크 스팰을 유발해 성능이 낮아진다
• 너무 크면 동시 작업 시 OOM(메모리 부족)을 유발한다

기본 계산법

대략적인 최대 메모리 소비량을 계산하려면 다음 공식을 사용한다.

# 총 예상 메모리 소비량(최대) = work_mem * max_connections * avg_sorts_per_connection
# 예: work_mem=16MB, max_connections=100, avg_sorts_per_connection=2
# 총 = 16MB * 100 * 2 = 3200MB

이 값은 최악의 경우의 추정치다. 실제로는 모든 연결이 동시에 정렬을 수행하지 않는다. 따라서 평균 동시 정렬 수를 추정해 보수적으로 적용한다.

설정 예제와 계산 예시

예상 운영 서버: RAM 32GB, 전용 DB, 동시 연결 평균 100명, 평균 활성 정렬 단계 1.5

• shared_buffers 시작값: 32GB의 25% = 8GB
• work_mem 목표 총 사용을 4GB로 제한하려면: work_mem = 4GB / (100 * 1.5) ≈ 27MB

# postgresql.conf 예시
shared_buffers = '8GB'
work_mem = '27MB'
# 필요한 경우 세부 조정
max_connections = 100

실무 적용 순서

1. 현재 설정과 메모리 사용량 확인
2. shared_buffers를 적정 비율로 설정 후 서비스 재시작 또는 리로드
3. work_mem을 계산해 점진적으로 적용
4. 대표 쿼리를 대상으로 벤치마크 수행
5. 모니터링 지표로 임계값 조정

모니터링 포인트

• pg_stat_activity: 동시 쿼리 패턴 파악
• pg_stat_database_conflicts, pg_stat_bgwriter: 버퍼 활동 확인
• OS의 메모리 사용량과 스왑 사용 여부
• EXPLAIN(ANALYZE)로 쿼리의 정렬/해시 사용 확인

검증과 튜닝 반복

설정 후에는 반드시 부하 테스트와 실서비스 모니터링을 병행해야 한다. 작은 변경을 하나씩 적용하고, 각 변경 후 효과를 측정한다. 자동화된 모니터링 알림을 설정하면 이상 징후를 빠르게 감지할 수 있다.

요약

shared_buffers는 서버 캐시 역할을 하고, work_mem은 정렬과 해시에 할당되는 작업 메모리다. 시작값으로 shared_buffers는 전체 RAM의 20~40% 범위를 고려하고, work_mem은 동시성에 따른 총 사용량을 계산해 결정한다. 실제 운영에서는 모니터링과 반복 검증이 최종 결정의 핵심이다.