8장. VACUUM과 Autovacuum — 청소부 없는 MVCC는 없다

UPDATE와 DELETE가 남긴 dead tuple은 저절로 사라지지 않습니다. Bloat 폭증, 쿼리 지연, 그리고 최악의 장애 XID Wraparound까지 — PostgreSQL 운영 사고의 절반은 여기서 시작됩니다.

8.1 왜 VACUUM이 필요한가 — 지워도 지워지지 않는 데이터

3장에서 배웠듯이 PostgreSQL의 UPDATE는 "기존 튜플에 xmax 표시 + 새 버전 삽입"이고, DELETE는 xmax만 표시할 뿐 물리적으로 지우지 않습니다. 마치 아파트에서 이사를 나가도 이전 집 짐을 그대로 두고 새 집으로 옮기는 것과 같습니다. 누군가 이전 집을 치워주지 않으면 아파트는 빈 짐으로 가득 차게 되죠.

이 "빈 짐"이 바로 dead tuple이고, 치워주는 청소부가 VACUUM입니다. 청소를 안 하면 네 가지 문제가 생깁니다.

• Bloat: 테이블·인덱스가 실제 데이터보다 몇 배로 부풀어 스캔 I/O 증가, 캐시 효율 저하
• XID Wraparound: 32비트 트랜잭션 ID가 순환하며 "과거 커밋이 미래처럼 보이는" 재앙
• Index-Only Scan 불가: Visibility Map이 갱신되지 않아 항상 heap 접근
• 통계 부정확: pg_class.reltuples 오류로 플래너가 잘못된 계획을 세움

8.2 VACUUM이 실제로 하는 일 — 그리고 하지 않는 일

일반 VACUUM(lazy vacuum)은 생각보다 많은 일을 합니다. dead tuple 회수는 그중 하나일 뿐입니다.

1. Heap 스캔 — 페이지를 읽어 dead tuple 식별
2. 인덱스 정리 — dead tuple을 가리키는 인덱스 엔트리 제거
3. 공간 회수 — dead tuple의 line pointer를 재사용 가능 상태로 표시
4. FSM/VM 갱신 — 빈 공간 지도와 Visibility Map(all-visible/all-frozen) 갱신
5. 통계 갱신 — pg_class.reltuples, relpages
6. Freeze — 오래된 튜플의 xmin을 FrozenXid로 교체 (8.4에서 자세히)

-- 자주 쓰는 VACUUM 옵션
VACUUM (VERBOSE, ANALYZE) orders;       -- 상세 로그 + 통계 갱신
VACUUM (FREEZE) orders;                 -- 가능한 모든 튜플을 즉시 frozen
VACUUM (PARALLEL 4) orders;             -- 인덱스 병렬 정리 (13+)

-- 진행 중인 VACUUM 실시간 확인 (9.6+)
SELECT pid, relid::regclass, phase,
       heap_blks_total, heap_blks_scanned, num_dead_tuples
FROM pg_stat_progress_vacuum;

8.3 Autovacuum — 청소부는 언제 자동으로 출근하는가

매번 수동으로 VACUUM을 돌릴 수는 없으니, PostgreSQL은 Autovacuum Launcher라는 관리자를 둡니다. Launcher는 autovacuum_naptime(기본 1분)마다 깨어나 통계를 살펴보고, 청소가 필요한 테이블에 워커를 파견합니다. 파견 기준은 명확한 공식입니다.

-- VACUUM 트리거 공식 (기본값 기준)
n_dead_tup  >  autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × reltuples
            =  50 + 0.2 × 행수

-- 예: 100만 행 테이블 → dead tuple이 200,050개를 넘어야 autovacuum이 돈다
-- ANALYZE 트리거는 별도: 50 + 0.1 × 행수

기본값의 함정: scale_factor = 0.2는 10억 행 테이블에서 2억 개의 dead tuple이 쌓여야 청소가 시작된다는 뜻입니다. 큰 테이블일수록 개별 설정으로 문턱을 낮춰야 합니다.

-- 핫 테이블은 개별 storage parameter가 정답
ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.02,   -- 20% → 2%로 낮춤
  autovacuum_vacuum_threshold = 10000,
  autovacuum_vacuum_cost_limit = 2000,     -- 더 빠르게 청소
  fillfactor = 85                          -- HOT 업데이트용 여유 공간
);

8.4 XID Wraparound — 가장 위험한 장애와 Freeze

PostgreSQL의 트랜잭션 ID(XID)는 32비트, 약 40억 개입니다. 다 쓰면 0부터 다시 시작하는 순환 구조죠. 문제는 MVCC의 가시성 판정이 "내 XID보다 과거인가/미래인가" 비교에 의존한다는 것입니다. XID가 한 바퀴 돌면 아주 오래된 과거 커밋이 갑자기 미래처럼 보이는 — 즉 데이터가 사라져 보이는 재앙이 일어납니다.

방지책이 Freeze입니다. 충분히 오래된 튜플의 xmin을 특수값 FrozenXid로 바꿔 "누가 봐도 무조건 과거"로 만들어 XID를 재활용할 수 있게 합니다.

조기 경보는 간단한 쿼리 하나면 됩니다. 일간 모니터링에 반드시 포함하세요.

-- 테이블별 frozenxid 나이 — 5억 넘으면 WARN, 15억 넘으면 CRITICAL
SELECT c.relname,
       age(c.relfrozenxid) AS xid_age,
       pg_size_pretty(pg_table_size(c.oid)) AS size
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','m')
  AND n.nspname NOT IN ('pg_catalog','information_schema')
ORDER BY age(c.relfrozenxid) DESC LIMIT 20;

8.5 VACUUM을 막는 4대 요인

VACUUM은 "현재 활성인 가장 오래된 스냅샷보다 더 오래된" dead tuple만 회수할 수 있습니다. 누군가 오래된 스냅샷을 붙들고 있으면, VACUUM이 아무리 부지런히 돌아도 헛돌게 됩니다.

-- 범인 색출: 가장 오래된 xmin을 붙들고 있는 세션
SELECT pid, usename, state,
       now() - xact_start AS tx_age,
       age(backend_xmin) AS xmin_age,
       left(query, 100) AS q
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL
ORDER BY age(backend_xmin) DESC LIMIT 10;

✍️ 이해도 체크