Skip to content

VACUUM (정리·튜닝·autovacuum)

개요

PostgreSQL은 주기적인 관리 작업이 필요한데, 그 중심이 VACUUM(백큠) 이에요. 처음 보면 "왜 DB가 스스로 정리를 안 하지?" 싶지만, 이유는 MVCC에 있어요 — 앞에서 본 것처럼 PostgreSQL은 행을 지우거나 바꿀 때 이전 버전을 바로 없애지 않고 남겨둬요. 그 남은 예전 버전(dead tuple)을 치우지 않으면 디스크가 계속 늘어나요. 이 페이지는 그 VACUUM이 왜 필요한지, 어떻게 동작하는지, 그리고 자동화된 autovacuum을 어떻게 튜닝하는지를 공식 문서 기준으로 풀어요.

핵심 개념

VACUUM이 하는 일 (왜 정기적으로 필요한가)

공식 문서는 VACUUM이 각 테이블을 정기적으로 처리해야 하는 이유를 네 가지로 나눠요.

  1. 디스크 공간 회수 — UPDATE·DELETE로 생긴 이전 버전이 차지하는 공간을 되살리거나 재사용해요.
  2. 플래너 통계 갱신 — 쿼리 플래너가 좋은 계획을 세우도록 ANALYZE로 통계를 수집해요.
  3. visibility map 갱신 — 모든 트랜잭션에 보이는 페이지만 추려내는 지도를 갱신해, 인덱스 전용 스캔을 빠르게 해줘요.
  4. 트랜잭션 ID 래퍼라운드 방지 — 아주 오래된 데이터의 손실을 막아요(아래에서 자세히).

VACUUM vs VACUUM FULL

  • 표준 VACUUM — 죽은 행 버전을 치우고 공간을 재사용 가능하게 표시해요. 하지만 공간을 운영체제에 되돌려주진 않아요(특수한 경우 제외). 대신 운영 중인 트랜잭션과 병렬로 돌 수 있어서 부담이 작아요.
  • VACUUM FULL — 테이블 전체를 새로 써서 디스크 공간을 확실히 줄여요. 하지만 ACCESS EXCLUSIVE 잠금이 필요해서 다른 작업과 병렬로 못 돌고, 속도도 훨씬 느려요.

즉 평소엔 표준 VACUUM을 자주 돌리는 게 좋아요. 공식 문서는 "슈퍼 관리자는 표준 VACUUM을 쓰고 VACUUM FULL은 피하도록 노력하라"고 권장해요.

트랜잭션 ID 래퍼라운드 — VACUUM이 생명인 이유

PostgreSQL의 트랜잭션 ID(XID)는 32비트라서, 약 40억 개 트랜잭션을 넘기면 래퍼라운드(wraparound) 가 일어나요. 그러면 과거 트랜잭션이 갑자기 미래처럼 보여서 치명적인 데이터 손실이 날 수 있어요. VACUUM이 행을 frozen 상태로 표시하면, 그 행은 나이와 무관하게 "과거"로 취급돼서 래퍼라운드의 영향을 받지 않아요. 그래서 모든 데이터베이스의 모든 테이블을 20억 트랜잭션 안에 한 번은 VACUUM해야 해요.

autovacuum — 자동 정리 데몬

PostgreSQL은 autovacuum 데몬으로 VACUUM과 ANALYZE를 자동 실행해요. 기본적으로 켜져 있고, 테이블에 변경(UPDATE·DELETE·INSERT)이 충분히 많아지면 자동으로 VACUUM·ANALYZE를 돌려요. 특정 임계값을 넘으면 동작하는데, 예를 들어 "마지막 VACUUM 이후 줄어든 테이블 수"가 autovacuum_vacuum_threshold(기본 50) + autovacuum_vacuum_scale_factor(기본 0.2) × 테이블 행 수 를 넘으면 VACUUM을 돌려요.

autovacuum은 VACUUM FULL은 절대 안 하고, 래퍼라운드 위험(예: autovacuum_freeze_max_age, 기본 2억)에 가까워지면 비활성 상태에서도 강제로 돌아요. 그래서 대부분의 설치에서는 autovacuum에 맡겨도 충분해요.

사용 사례 / 실제 적용

  • autovacuum은 켜두기 — 기본 설정으로 자동 정리를 맡겨요. 특별한 이유 없이 데몬을 끄는 건 위험해요.
  • 핫 테이블은 표준 VACUUM 추가 — UPDATE·DELETE가 매우 잦은 테이블은 autovacuum만으로는 공간이 계속 늘 수 있어요. 부하가 낮은 시간에 표준 VACUUM을 보태거나, 테이블별로 임계값을 조정해요.
  • 래퍼라운드 모니터링 — pg_database의 datfrozenxid 나이(age(datfrozenxid))를 봐서, VACUUM 부족으로 위험에 가까워진 DB가 없는지 확인해요. 경고 문구가 나오기 전에 잡는 게 좋아요.
  • 디스크 확보가 정말 필요할 때만 VACUUM FULL — 공간을 운영체제로 확실히 되돌려야 할 때만 쓰되, 잠금과 느린 속도를 감안해 유지보수 창구에서 실행해요.
  • visibility map 점검 — VACUUM이 visibility map을 갱신하면 index-only scan이 빨라져요. 조회가 많은 테이블은 정리가 곧 조회 성능과 연결돼요.

더 알아보기