PostgreSQL 설정 계산기
브라우저 안에서만 처리됩니다. 입력한 내용과 선택한 파일은 서버로 전송되지 않습니다. 익명 방문 통계만 집계합니다.
이 값은 일반 산식으로 낸 출발점입니다. 실제 부하로 계측하며 조정하세요. 산식은 공개 프로젝트 pgtune 을 따랐습니다(리눅스 서버 가정). pgtune 원본
서버 전체가 아니라 DB 에 줄 수 있는 메모리
postgresql.conf 권장값
postgresql.conf 스니펫
# pgtune 워크로드 기본값(200) (재시작 필요) # 출처: https://www.postgresql.org/docs/17/runtime-config-connection.html#GUC-MAX-CONNECTIONS max_connections = 200 # RAM 의 25% (재시작 필요) # 출처: https://www.postgresql.org/docs/17/runtime-config-resource.html#GUC-SHARED-BUFFERS shared_buffers = 1GB # RAM 의 75% # 출처: https://www.postgresql.org/docs/17/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE effective_cache_size = 3GB # RAM 의 1/16, 최대 8GB # 출처: https://www.postgresql.org/docs/17/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM maintenance_work_mem = 256MB # 체크포인트를 다음 체크포인트 전까지 고르게 분산(고정값) # 출처: https://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET checkpoint_completion_target = 0.9 # shared_buffers 의 3%, 32kB~16MB 사이로 제한 (재시작 필요) # 출처: https://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-WAL-BUFFERS wal_buffers = 16MB # 워크로드별 체크포인트 세그먼트 여유(하한) # 출처: https://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-MIN-WAL-SIZE min_wal_size = 1GB # 워크로드별 체크포인트 세그먼트 여유(상한) # 출처: https://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-MAX-WAL-SIZE max_wal_size = 4GB # 기본 통계 목표치 # 출처: https://www.postgresql.org/docs/17/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET default_statistics_target = 100 # SSD/SAN — 랜덤 접근 비용을 낮게 평가 # 출처: https://www.postgresql.org/docs/17/runtime-config-query.html#GUC-RANDOM-PAGE-COST random_page_cost = 1.1 # 스토리지별 동시 비동기 I/O 기대치(Linux 기준) # 출처: https://www.postgresql.org/docs/17/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY effective_io_concurrency = 200 # (RAM - shared_buffers) / ((max_connections + 병렬 작업자 수) × 3), 워크로드별 배율 적용, 최소 4MB # 출처: https://www.postgresql.org/docs/17/runtime-config-resource.html#GUC-WORK-MEM work_mem = 5041kB
| 파라미터 | 권장값 | 근거 | |
|---|---|---|---|
| max_connections | 200 | pgtune 워크로드 기본값(200) 출처 | 재시작 |
| shared_buffers | 1GB | RAM 의 25% 출처 | 재시작 |
| effective_cache_size | 3GB | RAM 의 75% 출처 | |
| maintenance_work_mem | 256MB | RAM 의 1/16, 최대 8GB 출처 | |
| checkpoint_completion_target | 0.9 | 체크포인트를 다음 체크포인트 전까지 고르게 분산(고정값) 출처 | |
| wal_buffers | 16MB | shared_buffers 의 3%, 32kB~16MB 사이로 제한 출처 | 재시작 |
| min_wal_size | 1GB | 워크로드별 체크포인트 세그먼트 여유(하한) 출처 | |
| max_wal_size | 4GB | 워크로드별 체크포인트 세그먼트 여유(상한) 출처 | |
| default_statistics_target | 100 | 기본 통계 목표치 출처 | |
| random_page_cost | 1.1 | SSD/SAN — 랜덤 접근 비용을 낮게 평가 출처 | |
| effective_io_concurrency | 200 | 스토리지별 동시 비동기 I/O 기대치(Linux 기준) 출처 | |
| work_mem | 5041kB | (RAM - shared_buffers) / ((max_connections + 병렬 작업자 수) × 3), 워크로드별 배율 적용, 최소 4MB 출처 |
사용법
- 서버 사양(DB에 줄 메모리·코어·스토리지)과 워크로드를 고릅니다.
- 권장값이 즉시 계산됩니다 — 스니펫을 복사해 postgresql.conf에 붙여넣으세요.
- "재시작" 표시가 있는 값은 reload가 아니라 서버 재시작이 필요합니다.
자주 묻는 질문
이 값을 그대로 쓰면 되나요?
출발점으로 쓰세요. 일반 산식은 서버 사양만 보고 계산할 뿐 실제 쿼리 패턴을 모릅니다. 적용 후 실제 부하에서 계측하며 조정하는 것이 정석입니다.
shared_buffers를 메모리 전부로 주면 안 되나요?
PostgreSQL은 OS 페이지 캐시를 함께 활용하도록 설계돼 있어, 공식 문서도 통상 메모리의 25% 수준을 권장합니다. 나머지 메모리는 OS 캐시와 work_mem(쿼리별 작업 메모리)이 씁니다.
어떤 값이 재시작 없이 적용되나요?
표의 "재시작" 표시가 기준입니다. 표시가 없는 값은 pg_reload_conf() 또는 SIGHUP으로 적용되고, shared_buffers처럼 표시가 있는 값은 서버 재시작이 필요합니다.
느린 쿼리는 설정만으로 해결되나요?
아니요. 설정은 바닥을 깔아줄 뿐, 개별 쿼리 병목은 실행계획을 봐야 합니다. 실행계획 분석 도구에 EXPLAIN ANALYZE 출력을 붙여넣어 보세요.