HANDS-ON
00:00 경과
LABLAB-DB-13-VACUUM-BLOAT중급
VACUUM·테이블 부풀림 — dead tuple과 bloat 진단
ELAPSED
00:00
PHASE
0 / 3
SLA
40분
🗄️ Database
← 목록
INCIDENT RESPONSE
0 / 4 단계 완료
📚 PREREQUISITES
TRACK
DATABASE
SLA
40분
LEVEL
중급
PHASES
2단계
ENV
local
INCOMING TICKET
“운영 티켓: "events 테이블이 매주 커져서 디스크를 다 먹어요. 행은 천만 건인데 테이블 크기는 80GB예요. 매일 대량 UPDATE/DELETE 하는 테이블인데 정상인가요?"”
YOUR ROLE
주니어 인프라 엔지니어
안 하면 나중에
테이블 부풀림(bloat)으로 디스크 낭비·스캔 성능 저하 — 실제 데이터 대비 수 배 큰 테이블, 방치 시 디스크 풀로 쓰기 중단 위험
📋상황 브리핑
운영 티켓이 올라왔습니다.
"events 테이블이 매주 커져서 디스크를 거의 다 먹었어요. 행은 천만 건인데 테이블 파일 크기가 80GB나 돼요. 매일 대량으로 UPDATE/DELETE 하는 테이블인데, 이게 정상인가요? 데이터는 안 늘어나는데 왜 자꾸 커질까요?"
PostgreSQL의 MVCC는 UPDATE/DELETE 시 옛 버전 행(dead tuple)을 즉시 지우지 않고 남겨둡니다. 이게 쌓이면 테이블이 실제 데이터보다 훨씬 커집니다(bloat). pg_stat_user_tables로 dead tuple 비율과 autovacuum 동작을 확인하고, VACUUM으로 공간을 회수하며, autovacuum이 왜 못 따라갔는지를 진단합니다.
UPDATE 실행→옛 버전을 dead로 표시(즉시 안 지워짐)→새 버전 추가→VACUUM이 나중에 정리하는 MVCC 흐름과, pg_stat_user_tables의 n_live_tup·n_dead_tup·last_autovacuum 진단 컬럼, autovacuum 기본 임계치(전체 행의 20%+50개)를 매우 큰 테이블이나 쓰기 폭주 테이블이 못 따라가는 이유를 정리한 다이어그램확대
⏱ 40분📊 중급🔧 2단계#postgresql#vacuum#bloat#dead-tuple
MISSION
1
dead tuple과 bloat 진단
pg_stat_user_tables로 dead tuple 수·비율과 마지막 (auto)vacuum 시각을 확인해 부풀림을 진단한다
2
VACUUM으로 회수 + autovacuum 튜닝
VACUUM으로 dead tuple을 정리하고, VACUUM과 VACUUM FULL의 차이를 이해하며, autovacuum 임계치를 조정한다
📌 선수 지식
ℹ️ 실습 환경
환경: local
필요 도구: bash, postgresql, psql
🔒
실습 실행은 Pro 플랜 전용입니다
인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.
Pro로 업그레이드 →
>_ LAB WORKSPACE
NOTES