PostgreSQL 19 병렬 autovacuum, 베타4 시험서 리더 CPU 줄고 전체 시간은 거의 그대로

본문

PostgreSQL 19 beta4의 병렬 autovacuum은 Alex Georgiev가 시험한 테이블에서 전체 vacuum 시간을 거의 줄이지 않았지만, 리더 프로세스의 CPU 시간은 약 30% 줄였습니다. 병렬화는 인덱스 정리 단계에 적용됐고, 해당 시험의 병목이었던 테이블 본문(heap) 스캔에는 적용되지 않았습니다. PostgreSQL 19의 다른 유지보수 기능인 REPACK (CONCURRENTLY)는 읽기·쓰기를 유지하며 테이블 공간을 회수하는 대신 더 오래 걸리고 추가 디스크 공간을 씁니다. 한편 beta3에서 시험한 온라인 체크섬 전환은 beta4에서 철회돼 RC1에 포함되지 않았습니다.

Georgiev는 40만 행을 두 차례 갱신해 이전 행 버전인 죽은 튜플 80만 개를 만든 테이블을 시험했습니다. 테이블에는 인덱스가 여섯 개 있었습니다. 병렬 작업자를 쓰지 않은 세 차례 실행의 평균 시간은 1.31초였고, autovacuum_max_parallel_workers를 4로 둔 세 차례 실행은 평균 1.25초였습니다. 약 4% 차이는 저자가 관측한 실행 간 편차 안에 들었습니다. 반면 autovacuum 로그에 기록된 리더 CPU 시간은 직렬 실행의 0.55~0.57초에서 병렬 실행의 0.38~0.42초로 줄었습니다. 이 로그 값은 리더 프로세스의 CPU 시간만 나타내며 보조 작업자들의 CPU 시간을 포함하지 않습니다.

Georgiev의 설명에 따르면 병렬화가 적용된 구간과 실제 병목이 달랐습니다. PostgreSQL 19의 autovacuum_max_parallel_workers는 인덱스 vacuum 및 cleanup 단계에 쓸 작업자 수를 정합니다. 그의 시험에서는 여섯 인덱스 중 다섯 개의 스캔 작업이 보조 작업자로 넘어갔지만, heap 스캔은 병렬화되지 않았습니다. 저자는 heap 스캔과 그 과정에서 생성된 WAL이 시험의 병목이었다고 설명했습니다. 이 조건에서는 인덱스 작업을 나눠도 전체 작업시간이 크게 달라지지 않았습니다.

PostgreSQL 19 문서에서 autovacuum_max_parallel_workers의 기본값은 0으로, 이 설정에서는 autovacuum 중 병렬 vacuum이 꺼집니다. 병렬 작업자를 사용하려면 값을 0보다 크게 설정해야 하며, 실제 작업자 수는 서버 전체 병렬 작업자 풀인 max_parallel_workers의 여유에 제한됩니다. PostgreSQL Global Development Group은 RC1 발표에서 beta4 기간에 병렬 autovacuum 관련 수정 여러 건을 적용했다고 밝혔습니다. 따라서 Georgiev의 수치는 beta4의 특정 테이블과 설정에서 나온 결과이며, RC1에 반영된 수정 사항을 반영하지 않습니다.

데이터 페이지 체크섬은 페이지를 쓸 때 저장하고 읽을 때 검증해 손상을 감지합니다. 기존 pg_checksums 도구는 클러스터를 멈춘 상태에서 체크섬을 켜거나 끄는 방식이었습니다. Georgiev는 9월 22일 공개한 beta3 시험에서 756MB 클러스터를 중지하고 체크섬을 활성화한 뒤 재시작하는 오프라인 절차가 가장 빠른 실행에서 1.28초 걸렸다고 기록했습니다. 비슷한 크기인 775MB 클러스터에서 온라인 활성화 작업은 약 2.80~2.85초 걸렸습니다. SQL 함수 호출은 약 0.13초 만에 반환됐지만 실제 변환 작업은 백그라운드에서 계속됐습니다. 당시 구현은 서비스 중단 없이 변환하는 대신 전체 작업시간이 더 걸리는 방식이었습니다. PostgreSQL Global Development Group은 이틀 뒤인 9월 24일 beta4 발표에서 온라인 체크섬 활성화와 비활성화를 철회했습니다. 따라서 이 수치는 beta3 구현을 시험한 결과이며, 온라인 체크섬 전환은 RC1에 포함되지 않았습니다.

REPACK (CONCURRENTLY)는 체크섬 전환이나 autovacuum과 목적이 다릅니다. Autovacuum은 죽은 행이 차지한 공간을 재사용할 수 있게 정리하지만, REPACK는 테이블과 인덱스를 새 파일로 다시 써 운영체제에 공간을 돌려줍니다. 동시 모드에서는 새 사본을 만드는 동안 생긴 변경을 논리 디코딩으로 포착해 적용한 뒤 기존 파일과 새 파일을 교체합니다. PostgreSQL 문서는 재작성 중 테이블을 읽고 쓸 수 있지만, 파일을 교체하는 마지막 단계에서는 강한 잠금을 얻는다고 설명합니다.

Craig Kerstiens가 공개한 493MB 테이블 시험에서 VACUUM FULL은 2.7초 동안 작업 전체에 걸쳐 잠금을 잡았습니다. REPACK (CONCURRENTLY)는 9.4초 걸렸고 마지막 교체 단계에서만 강한 잠금을 사용했습니다. 시험 장비는 CPU 1개와 메모리 512MB였습니다. 동시 REPACK는 새 테이블과 인덱스 사본을 만드는 동안 그 크기에 해당하는 여유 디스크 공간도 필요합니다. PostgreSQL 문서는 이 방식이 완전한 MVCC 안전성을 제공하지 않는다고 명시합니다. 재작성 시작 전에 스냅샷을 얻은 트랜잭션은 작업이 끝난 뒤 해당 테이블을 빈 상태로 볼 수 있습니다.