PostgreSQL 튜닝 - Autovacuum 최적화에 대하여

구조와 흐름

• MVCC의 update·delete 과정에서 기존 tuple이 dead tuple로 잔존하고 Vacuum이 이를 FSM에 반환하는 구조
• dead tuple 누적으로 인한 Data Bloat, 디스크 I/O 증가, 통계 왜곡과 select 성능 저하 가능성
• Autovacuum의 scale factor·threshold 기반 실행 기준과 대용량 테이블에서의 지연 문제

해결 방법

• pg_stat_user_tables 기반 dead/live tuple 비율과 최근 vacuum·analyze 시각 모니터링
• 테이블별 autovacuum_vacuum_scale_factor 0 설정과 threshold 지정으로 실행 주기 고정
• autovacuum_vacuum_cost_limit, analyze 기준, work memory, worker 수의 환경별 조정

성능/운영 포인트

• 대규모·빈번한 update/delete 테이블에서 dead tuple 누적 전 조기 vacuum 유도
• autovacuum_max_workers 변경 시 PostgreSQL 재시작 필요와 XID Freeze 지연 위험 고려
• Full Vacuum의 테이블 lock·저장 공간 축소 효과와 Autovacuum의 공간 재사용 특성 구분

주의할 점

• 기본 Autovacuum 설정의 광범위한 호환성 중심 특성
• pg_repack 수행 중 시작·종료 순단과 높은 데이터베이스 리소스 소비 가능성
• 서비스별 트랜잭션·테이블 규모에 따른 지속적 모니터링과 개별 튜닝 필요