day-log

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

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

autovacuum이 돌고 있는 줄 알았다지난주에 PostgreSQL 디스크가 갑자기 부풀어오르는 사건이 있었다. 정확히는 이미 며칠 전부터 부풀고 있었는데, 우리가 늦게 알아챈 거다.처음에는 단순히 "데이터가 많아져서 그렇겠지" 생각했다. 그런데 dead tuple 비율을 찍어보니 40%를 넘기고 있었다. 어떤 테이블은 60%. 라이브 row보다 죽은 row가 더 많은 상태였다. autovacuum 로그를 뒤져보니 마지막 vacuum이 4일 전에 멈춰 있었다. 그리고 그 사이에 누가 무엇을 했는지 추적이 시작됐다.pg_stat_activity가 말해준 것pg_stat_activity 뷰를 열어보니 한 세션이 4일째 살아 있었다. state는 idle in transaction. xact_start는 월..