튜닝 2

Postgres autovacuum, 내부는 어떻게 도는가

autovacuum 이야기를 하면 대개 두 가지 반응이 나온다. 하나는 "그거 알아서 도는 거 아니냐"고, 다른 하나는 "우린 껐다"다. 둘 다 나름의 이유가 있는데, 결국 내부 동작을 잘 모르는 상태에서 기본값과 부딪히다 지친 사람들의 흔적이다. 사실 autovacuum은 상당히 정교한 스케줄러와 워커 조합이고, 각 파라미터가 어디에 걸려서 동작하는지 알면 튜닝이 아니라 그냥 논리적인 조합 문제가 된다.우리 팀에서는 최근 300GB 규모의 이벤트 로그 테이블에서 autovacuum이 "안 도는 것처럼" 보이는 문제를 파고들었다. 결론부터 말하면 안 돌던 게 아니라 계속 시작했다가 중간에 죽고 있었다. 이 이야기를 하려면 결국 내부 흐름부터 짚고 가야 한다.launcher와 worker의 관계Postgr..

IT/DB 운영 2026.07.19

PostgreSQL 17 autovacuum, 이제 maintenance_work_mem 상한 신경 안 써도 된다

지난주에 팀에서 PG16 → PG17 업그레이드 검증하다가 알게 된 건데, 이거 모르는 분 꽤 많더라. 짧게 하나만 짚고 넘어간다.핵심: 1GB 상한이 사라졌다PG16까지는 autovacuum_work_mem(또는 fallback으로 maintenance_work_mem)이 아무리 커도 실질적으로 1GB 제한이 있었다. dead tuple ID를 저장하는 자료구조가 단순 배열이었고, TIDStore가 아니라 6바이트짜리 ItemPointerData 배열이라 메모리 크기와 상관없이 내부적으로 1GB(정확히는 MaxAllocSize)까지만 쓸 수 있었기 때문이다.이게 뭐가 문제였냐면, 큰 테이블에서 dead tuple이 1GB 배열에 다 안 들어가는 순간 인덱스 vacuum 페이즈가 여러 번 반복된다. 인덱..

IT/DB 운영 2026.07.12