Enterprise Infrastructure Intelligence ● Certified engineers online · Fast response guaranteed
웹서버/DB

PostgreSQL Vacuuming: MVCC 기반 데이터베이스의 필수 정리 메커니즘

PostgreSQL의 Vacuuming은 다중 버전 동시성 제어(MVCC) 환경에서 발생하는 Dead Tuple을 제거하고 스토리지를 회수하는 핵심 메커니즘입니다. 트랜잭션 ID wraparound 방지와 쿼리 최적화를 위한 가시성 맵 유지를 동시에 수행합니다.

2026.09.02  ·  35회  · 

PostgreSQL Vacuuming의 아키텍처와 작동 원리

Vacuuming이란 무엇인가?
PostgreSQL의 VACUUM 명령은 MVCC 기반 아키텍처에서 UPDATE 또는 DELETE 작업으로 발생하는 Dead Tuple(이전 버전의 행)을 식별하고 제거하는 가비지 컬렉션 작업입니다. 중요한 점은 Old Tuple이 즉시 제거되지 않는다는 것입니다. 다른 트랜잭션이 여전히 그 행 버전을 참조할 수 있기 때문입니다.

두 가지 Vacuum 변형
VACUUM은 표준 모드와 VACUUM FULL로 나뉩니다. 표준 Vacuum은 Dead Space를 표시하여 재사용 가능하게 만들지만 OS로 반환하지 않으며, 다른 작업과 병렬 실행이 가능합니다. 반면 VACUUM FULL은 테이블 전체를 재작성하여 공간을 최소화하지만 배타적 lock이 필요하고 추가 디스크 공간을 소비하므로 용도가 제한됩니다.

Vacuum의 4가지 핵심 목적
(1) 디스크 공간 회수: Dead Tuple이 차지하던 공간을 표시하여 신규 행 삽입에 활용
(2) 플래너 통계 갱신: ANALYZE를 통해 쿼리 최적화 정보 업데이트
(3) 가시성 맵 유지: 특정 페이지의 모든 행이 모든 트랜잭션에 보이는지 추적하여 Index-Only Scan 활성화
(4) XID Wraparound 방지: 32비트 트랜잭션 ID의 순환 고갈로부터 데이터 손실 방지

Autovacuum의 다중 프로세스 아키텍처
자동 vacuuming은 단순 daemon이 아니라 다중 프로세스 구조를 가집니다. Autovacuum Launcher는 지속 실행되며 모든 DB별로 Autovacuum Worker를 시작합니다. Launcher는 autovacuum_naptime 간격(기본 1초)으로 각 DB마다 Worker 시작을 시도하며, 최대 autovacuum_max_workers(기본 3)개의 Worker가 동시 실행됩니다.

Autovacuum Trigger 메커니즘
Worker는 다음 조건을 만족하면 특정 테이블에 Vacuum을 실행합니다:
Dead Tuple 수 > autovacuum_vacuum_threshold + (autovacuum_vacuum_scale_factor × reltuples)
또는 XID Age > autovacuum_freeze_max_age (기본 2억 트랜잭션)
또는 Insert 수 > autovacuum_vacuum_insert_threshold + (autovacuum_vacuum_insert_scale_factor × reltuples)

I/O 부하 관리와 비용 기반 제어
Vacuum은 상당한 I/O 트래픽을 생성하므로 autovacuum_vacuum_cost_delay와 autovacuum_vacuum_cost_limit 파라미터로 제어됩니다. 여러 Worker가 동시 실행될 경우 총 I/O 영향은 일정하게 유지되도록 비용이 분배됩니다.

XID Wraparound와 Aggressive Vacuum
PostgreSQL의 32비트 XID는 약 43억 트랜잭션 이후 0으로 순환합니다. 이를 방지하기 위해 Frozen Row 개념을 도입했습니다. FrozenTransactionId라는 특수 XID는 모든 일반 XID보다 과거로 취급되어 Wraparound와 무관하게 유효합니다. VACUUM FREEZE 옵션이나 Aggressive Vacuum(테이블 전체 스캔)을 통해 오래된 Row를 Freeze합니다.

실무 주의점
1) Vacuum 중 SHARE UPDATE EXCLUSIVE Lock과 충돌하는 작업(예: ANALYZE)은 Vacuum을 중단시킬 수 있으므로 정기적 ANALYZE 스케줄링에 주의
2) 많은 Dead Tuple 발생 시 표준 Vacuum이 불충분하면 VACUUM FULL이나 CLUSTER 명령을 고려하되 별도 디스크 공간과 장시간 Lock 필요
3) 파티션 테이블과 외부 테이블은 별도 수동 관리 필요 (Autovacuum은 파티션은 처리하지만 부모 테이블 ANALYZE는 자동 실행 안 함)
4) 저활동 테이블의 경우 autovacuum_freeze_max_age를 증대하여 불필요한 Aggressive Vacuum 빈도 감소 가능
5) pg_stat_progress_vacuum 뷰로 실시간 Vacuum 진행 상황 모니터링 및 log_autovacuum_min_duration으로 장시간 작업 추적

WIKIDATA WORKSTATION
AI·렌더링에 최적화된
전문가용 워크스테이션
NVIDIA RTX GPU · 최대 192GB 메모리 · ECC 지원