앞선 두 편에서 VACUUM이 공간을 반환하지 않는다는 것과 autovacuum 발동 조건을 다뤘다. 이번 편은 성격이 다르다. 설정을 아무리 만져도 해결되지 않는 경우가 있다. autovacuum은 정상적으로 돌고, 실행 기록도 계속 갱신되는데, 죽은 튜플만 계속 늘어난다. 이건 VACUUM이 게을러서가 아니라 지울 권한이 없어서다. 정리 기준선 VACUUM은 아무 죽은 튜플이나 지우지 않는다. 지워도 되는지 판단하는 기준선이 있다. 기준은 단순하다. 지금 실행 중이거나 앞으로 시작할 어떤 트랜잭션도 이 튜플을 볼 수 없는가. 하나라도 볼 가능성이 있으면 못 지운다. 지웠다가는 그 트랜잭션이 읽어야 할 데이터가 사라진다. ...

지난 편에서 죽은 튜플 비율이 계속 올라가고 있다면 설정을 봐야 한다고 썼다. 그 설정 이야기다. 결론부터 말하면, autovacuum의 기본값은 작은 테이블에 맞춰져 있다. 테이블이 커질수록 늦게 돌고, 늦게 도는 만큼 한 번에 할 일이 많아진다. 발동 조건 공식 autovacuum은 테이블마다 임계값을 계산해서, 죽은 튜플 수가 그 값을 넘으면 대상으로 잡는다. 발동 임계값 = autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × 테이블 행 수 기본값은 이렇다. 파라미터 기본값 autovacuum_vacuum_threshold 50 autovacuum_vacuum_scale_factor 0.2 (20%) 지배적인 건 뒤쪽 항이다. 행 수에 곱해지기 때문이다. ...

VACUUM을 돌렸는데 디스크가 그대로라는 이야기를 종종 듣는다. 정상 동작이다. VACUUM은 공간을 운영체제에 돌려주는 명령이 아니다. VACUUM이 실제로 무엇을 하는지, bloat가 왜 쌓이고 어떻게 재는지까지 정리한다. 죽은 튜플은 어떻게 생기는가 PostgreSQL은 MVCC를 쓰기 때문에 UPDATE가 제자리 수정이 아니다. 기존 행을 고치는 게 아니라 새 버전을 하나 더 쓰고, 예전 버전에 “이 시점 이후로는 무효"라는 표시를 남긴다. DELETE도 마찬가지로 즉시 지우지 않고 무효 표시만 한다. 예전 버전을 바로 못 지우는 이유는 아직 그걸 봐야 하는 트랜잭션이 있을 수 있어서다. 먼저 시작된 트랜잭션에게는 여전히 그 버전이 유효한 데이터다. ...

두 달 동안 관찰 모드로 돌려둔 기능이 있었다. 실제 차단은 하지 않고 “차단했을 것"만 로그로 남기는 방식이었다. 전환 시점이 되어 로그를 확인했더니 관련 로그가 한 줄도 없었다. 처음 든 생각은 “오탐이 0이구나, 안전하게 켜도 되겠다"였다. 다행히 켜기 전에 한 번 더 봤는데, 실제로는 오탐이 0이 아니라 관찰 결과가 한 시간 이상 남지 않는 상태였다. 로그를 매시간 비우는 크론이 따로 돌고 있었던 것이다. 두 달치 관찰을 했다고 믿었지만 실제로 본 것은 직전 몇십 분이었다. 그 뒤로 비슷한 유형을 몇 번 더 밟았고, 공통점이 있어서 정리해둔다. 전부 관찰 결과가 관찰 대상보다 먼저 사라지는 문제다. ...

배포 전에 지우는 로그 console.log를 잔뜩 박아두고 배포 직전에 전부 지워본 적이 있다면, 그건 로깅이 아니라 디버깅이다. 둘은 목적이 다른 별개의 활동이다. 디버깅 로깅 수명 일시적 영구적 시점 개발 중 운영 중에 더 중요 독자 사람 사람 + 기계 형식 자유 구조화 배포 시 삭제 남는다 운영에서의 로깅은 6개월 뒤에 누군가가 어제 새벽 2시에 무슨 일이 있었는지 검색할 수 있게 만드는 일이다. 그러려면 형식이 있어야 하고, 검색 가능해야 하고, 보관돼야 한다. 이 세 조건을 하나씩 짚어보려 한다. ...