VACUUM과 일상 점검

결론부터

PostgreSQL은 변경 뒤의 정리와 통계 갱신이 필요하며, 오래 열린 트랜잭션은 그 일을 방해할 수 있다.

UPDATE가 기존 행을 즉시 지워 버리면 이전 스냅샷을 읽는 연결은 자신에게 필요한 값을 잃는다. 그래서 이전 행 버전은 더 이상 필요하지 않을 때 정리한다.

이 장에서 처음 나오는 말3개

VACUUM

더 이상 필요하지 않은 행 버전의 공간을 재사용 가능하게 하고 트랜잭션 ID 관리도 돕는 유지 작업.

autovacuum

테이블 상태에 따라 VACUUM과 ANALYZE를 자동 수행하는 작업 체계.

ANALYZE

실행 계획에 필요한 데이터 분포 통계를 수집한다.

삭제했는데 파일이 줄지 않는 이유

일반 VACUUM은 주로 테이블 내부 공간을 다음 쓰기에 재사용하도록 만든다. DELETE한 만큼 파일 크기가 바로 줄어드는 것은 아니다. VACUUM FULL은 테이블을 다시 쓰고 강한 잠금과 추가 공간을 요구하므로 일상 정리의 기본 명령으로 두지 않는다. (정기 VACUUM)

autovacuum을 끄면 당장 부하가 줄어 보여도 정리할 양과 오래된 트랜잭션 ID 문제가 쌓일 수 있다. 장시간 트랜잭션이 이전 스냅샷을 유지하면 VACUUM이 필요한 버전을 제거할 수 없다. VACUUM 작업 횟수만 늘리기 전에 무엇이 오래된 상태를 붙잡는지 확인한다.

테이블별 정리 상태

공통 예제에서 실행한다.

SELECT relname, n_live_tup, n_dead_tup,
       last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY relname;

projects·tasks와 추정 행 수가 보인다. 작은 새 테이블은 자동 정리 시각이 NULL이어도 이상하지 않다. 통계는 추정과 지연이 있으므로 방금 수행한 UPDATE 수와 정확히 일치한다고 가정하지 않는다. (누적 통계 뷰)

VACUUM (ANALYZE) public.tasks;

이 명령은 BEGIN 안이 아닌 자동 커밋 상태에서 실행한다. 수동 실행 결과는 last_vacuum·last_analyze에서 확인한다. 이는 복원해야 할 업무 데이터 변경은 아니다.

오래 열린 트랜잭션 찾기

SELECT pid, usename, state,
       now() - xact_start AS transaction_age,
       wait_event_type, wait_event
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

idle in transaction은 연결은 쉬고 있지만 트랜잭션이 끝나지 않았다는 뜻이다. 앱이 commit·rollback을 빠뜨렸는지 확인한다. 조회 권한에 따라 다른 세션의 상세 정보는 제한될 수 있다. 조회된 PID를 곧바로 종료하기보다 그 작업과 차단 관계를 먼저 파악한다.

알림을 어떤 행동과 연결하나

신호	이어서 볼 것
dead tuple 추정치가 계속 증가	변경량, autovacuum 실행·완료 여부, 오래된 트랜잭션
예상 행 수와 실제 행 수가 크게 다름	최근 대량 변경, ANALYZE 시점, 컬럼 분포
디스크 사용량 지속 증가	테이블·인덱스 증가와 WAL 누적을 분리
연결은 많은데 처리량은 낮음	잠금 대기, 긴 트랜잭션, 연결 풀 대기

이해 확인: WAL 디렉터리가 커지면 VACUUM FULL로 해결할까? 아니다. WAL 보존 원인과 아카이브 실패를 확인해야 한다.