VACUUM이 중요한 이유

PostgreSQL은 내부적으로 MVCC (Multi-Version Concurrency Control) 라는 트랜잭션 관리 방식을 사용합니다.

MVCC는 데이터를 수정하거나 삭제할 때 기존 데이터를 곧바로 삭제하지 않고, 새로운 버전을 만들어 저장합니다.

죽은 튜플은 디스크 공간을 차지하고, 쿼리 성능을 저하시킵니다.

그래서 PostgreSQL은 이를 주기적으로 "청소"해야 하는데, 이게 바로 VACUUM입니다.


VACUUM이 하는 일

역할설명
🧹 죽은 튜플 제거삭제되었거나 수정된 이전 버전의 레코드 제거
♻️ 디스크 공간 재사용 가능화삭제된 공간을 다른 데이터가 사용 가능하도록 표시
🔐 트랜잭션 ID 감쇠 방지트랜잭션 ID 오버플로우를 방지 (중요!)
📈 통계 수집(ANALYZE)쿼리 최적화를 위한 테이블/컬럼 통계 갱신 (옵션)

VACUUM 종류

명령어특징
VACUUM죽은 튜플을 정리하지만, 파일 크기는 줄이지 않음
VACUUM FULL테이블을 재작성해 디스크 공간도 줄임
VACUUM ANALYZE정리와 함께 통계도 갱신

Autovacuum: 자동화된 VACUUM

PostgreSQL은 autovacuum 프로세스를 통해 백그라운드에서 자동으로 VACUUM을 수행합니다.

하지만 모든 상황에서 충분하지 않을 수 있습니다.

상황Autovacuum 한계
대량 업데이트 / 삭제autovacuum이 너무 늦게 실행되어 성능 저하 발생
대용량 테이블autovacuum이 완료되기 전에 다시 트래픽 증가 → VACUUM 지연
빠른 ID wraparound 위험autovacuum이 주기를 놓치면 데이터베이스 전체가 정지될 수 있음

VACUUM 상태 확인

1. 마지막 vacuum 수행 시간 확인

SELECT relname, last_vacuum, last_autovacuum
FROM pg_stat_user_tables
ORDER BY last_autovacuum DESC;

2. dead tuple 수 확인

SELECT relname, n_dead_tup
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;

3. autovacuum 진행 확인

SELECT * FROM pg_stat_activity WHERE query LIKE '%vacuum%';

VACUUM을 게을리하면 발생할 수 있는 문제

문제설명
쿼리 성능 저하죽은 튜플이 많아지면 쿼리가 더 많은 블록을 읽게 됨
디스크 공간 낭비실제 사용하지 않는 블록이 남아 공간 낭비
트랜잭션 ID wraparound심각할 경우 데이터베이스 전체 정지 위험 발생 ❗️
인덱스 Bloat정리되지 않은 인덱스도 성능 저하 유발

  • 대량 삭제/수정 후에는 수동 VACUUM FULL 고려
  • 큰 테이블은 스케줄링하여 off-peak 시간에 VACUUM 수행
  • autovacuum 설정 조정으로 민감 테이블 조절
    autovacuum_vacuum_scale_factor = 0.1
    autovacuum_vacuum_threshold = 50
    

TarzanDB Vacuum Monitoring

TarzanDB는 DBMS 성능 저하 방지 및 안정적인 시스템 운영을 위한 실시간 Vacuum Monitoring 기능과 Vacuum 설정(Tuning) Guide를 제공합니다.

핵심 차별 기능

  • PostgreSQL은 Dead Tuple 관리 및 Table Reorganize 등을 위해 주기적인 관리 작업인 Vacuum 수행
  • Dead Tuple이 많은 경우, 빈번한 Vacuum이 발생되고, 이는 DBMS 성능 저하를 유발하여 PostgreSQL의 주요 이슈 사항
  • 특히 데이터가 많은 Table에서 Lock이 발생하는 Vacuum Full은 서비스 장애 유발
  • TarzanDB는 빈번한 Vacuum, Vacuum Full 발생에 대한 체계적인 모니터링을 수행하고, 안정적인 운영 지원을 위한 개선 방안 제시
profile
안녕하세요. 엔텔스 TarzanDB 공식계정입니다.

0개의 댓글