▲

Postgres 18을 기다리며: 비동기 I/O로 디스크 읽기 속도 향상

 (pganalyze.com)
1P by GN⁺ 15시간전 | ★ favorite | 댓글 1개
  • 현재 베타1인 Postgres 18은 비동기 I/O (Asynchronous I/O) 지원을 도입하며, 특히 클라우드 환경에서의 읽기 성능을 크게 개선함
  • 새로운 설정값 io_method를 통해 전통적 sync 방식 외에 worker, io_uring 방식을 선택할 수 있음
  • AWS 기준 벤치마크 결과, io_uring 사용 시 디스크 읽기 성능이 최대 3배 향상됨
  • 다만, 비동기화로 인해 기존 쿼리 분석(EXPLAIN ANALYZE)의 I/O 타이밍 해석이 더 어려워짐
  • 새로운 모니터링 뷰(pg_aios) 와 튜닝 파라미터(effective_io_concurrency) 를 통해 성능 최적화 필요

Postgres 18의 비동기 I/O 도입

  • 전통적으로 Postgres는 블로킹 I/O 모델을 사용해, 각 디스크 읽기가 완료될 때까지 대기
  • 네트워크 기반 스토리지(EBS 등)에서의 높은 지연시간으로 인해 클라우드 환경에서 병목 현상 발생
  • 비동기 I/O는 여러 디스크 읽기를 병렬로 처리 가능하게 하며, CPU 활용도와 전체 처리량을 높임

Postgres 17의 사전 작업: Read Stream API

  • Postgres 17에서는 read_stream API를 도입해 읽기 작업의 추상화를 표준화
  • 하지만 이는 여전히 OS 페이지 캐시에 의존하며 Postgres 자체의 shared buffer에는 직접 반영되지 않음
  • Postgres 18에서는 커널 힌트가 아닌 직접적인 비동기 읽기가 가능해짐

새로운 설정: io_method

  • Postgres 18은 postgresql.conf에 io_method 설정을 추가하며, 다음 3가지 옵션 제공:

io_method = sync

  • 기존 Postgres와 동일한 동기 방식
  • posix_fadvise() 기반의 읽기 선제 요청 방식 사용

io_method = worker (기본값)

  • I/O 전담 워커 프로세스가 비동기적으로 데이터를 읽고 공유 버퍼로 전달
  • 메인 프로세스는 읽기 작업 중단 없이 계속 실행 가능
  • 기본 워커 수는 3개이며, io_workers 설정으로 조정 가능

io_method = io_uring

  • Linux 커널 5.1 이상에서 사용 가능한 고성능 I/O 인터페이스
  • 워커 프로세스 없이도 직접 커널과 공유 링 버퍼를 통해 비동기 읽기 수행
  • 최신 커널, 파일시스템, 설정 요구됨

비동기 I/O의 성능 벤치마크 (AWS 기준)

  • 테스트 환경:
    • AWS c7i.8xlarge (32 vCPU, 64GB RAM)
    • 100GB io2 EBS, 20,000 IOPS
    • 3.5GB 규모의 테이블에 대해 SELECT COUNT(*) 실행

Cold cache 성능 비교:

| 버전/설정 | 실행 시간 (ms) |
|------------------|----------------|
| Postgres 17 (sync) | 15,831 |
| Postgres 18 (sync) | 15,071 |
| Postgres 18 (worker) | 10,052 |
| Postgres 18 (io_uring) | 5,723 |

  • io_uring은 sync 대비 2.8배 성능 향상
  • 클라우드에서의 디스크 지연 최소화에 탁월한 효과

effective_io_concurrency 튜닝

  • Postgres 18에서는 해당 파라미터가 내부 비동기 read-ahead 요청 수에 영향을 줌
  • 기본값이 1 → 16으로 상향되었으며, io_combine_limit과 곱해 최대 읽기 범위 결정
  • 고지연 클라우드 환경에서는 큰 값이 유리할 수 있으나, 워크로드별 벤치마크 필요

새로운 모니터링 도구: pg_aios

  • pg_stat_activity에서 비동기 작업 시 AioIoCompletion 이벤트로 나타나 백엔드의 대기 분석이 어려움
  • io_uring의 경우, 커널이 직접 처리하기 때문에 I/O 상태가 Postgres에서 보이지 않음
  • pg_aios 뷰를 통해 현재 진행 중인 비동기 요청의 상세 정보 확인 가능 
    SELECT * FROM pg_aios;
  • SUBMITTED, COMPLETED_IO 등의 상태와 대상 블록 정보 확인 가능

주의사항: I/O 타이밍 정보 해석 변화

  • 기존 EXPLAIN ANALYZE에서 보이던 I/O Timings은 동기 방식에서만 신뢰 가능
  • 비동기화된 worker, io_uring 사용 시에는 병렬 처리와 워커 분산으로 타이밍 정보 해석이 왜곡됨
  • 실제 I/O 노력 판단 시 shared read 버퍼 수와 pg_aios 활용이 권장됨

결론

  • Postgres 18은 읽기 중심 워크로드 성능 향상에 실질적 기여를 제공함
  • 특히 클라우드 환경의 고지연 디스크를 사용하는 경우 큰 이점을 얻을 수 있음
  • 동시에 관측 지표 해석, 성능 튜닝, 설정 적용 방식에 대한 재학습이 요구됨
  • 향후 Postgres 19에서는 비동기 쓰기 지원도 기대됨
▲
GN⁺ 15시간전  [-]
Hacker News 의견
  • Linux에서 preadv2(..., RWF_NOWAIT)를 사용하여 페이지 캐시에서 비동기 읽기를 수행할 수 있음. 이는 io_method = worker에서 지연 시간을 줄이는 데 유용할 수 있음
    • 메인 스레드에서 NOWAIT로 읽기를 시도하고 실패 시에만 작업 스레드로 오프로드하는 방법을 제안함
  • 이 새로운 비동기 I/O 기능이 Linux 전용인지에 대한 질문이 있음
    • Windows에는 IOCP와 자체 IORing 구현이 있으며, macOS는 POSIX AIO를 지원함
    • Windows의 IORing 구현에 대한 언급이 많지 않음을 지적함
  • FreeBSD의 aio(4)에 많은 작업이 이루어졌으며, Linux/glibc aio의 단점이 없다는 점에서 작동 방식이 흥미로울 것임
  • MySQL의 InnoDB와의 유사성에 대한 질문이 있음
  • io_uring의 보안 문제에 대한 우려가 있으며, 많은 Linux 관리자나 배포판에서 이를 비활성화하고 있는지에 대한 질문이 있음
  • NVMe에서 이러한 기능을 프로덕션에 적용하고 싶다는 의견이 있으며, 주요 클라우드 제공업체가 이를 ASAP 제공하기를 희망함
    • 성능 향상이 매우 매력적임
  • Hetzner EX-44 서버에 Postgres를 배포한 경험 공유
    • 가격 대비 성능 비율이 뛰어나며, 기업 수준의 용량을 저렴한 비용으로 제공함
    • TailScale을 사용하여 보안을 강화하고, 공용 네트워크 노출을 완전히 제거함
    • 최적화 접근 방식에는 PGTune을 통한 워크로드별 구성, PgHero를 통한 실시간 성능 모니터링, pgcron을 통한 자동 VACUUM ANALYZE 작업 등이 포함됨
    • ZSTD 압축 백업을 위한 사용자 정의 CLI 유틸리티를 개발하여 높은 압축 비율과 높은 처리량을 유지하며 자동 S3 업로드를 지원함
    • 이 설정은 안정적이고 성능이 뛰어나며, 성장 여력이 충분함
  • AWS 인스턴스의 20k IOPS에 대한 웃음 섞인 의견
    • 소비자 NVMe가 ~1백만+ IOPS를 제공하며, PCIe 5.0 NVMe로 인해 더 증가할 것으로 예상됨
    • 클라우드의 임의적인 제한이 많은 문제를 야기한다고 생각함
    • 비동기 IO가 매우 유용하지만, 1백만 IOPS NVMe에서는 중요성이 덜할 것임
    • 클라우드 비용이 매우 비싸며, 저렴한 소비자 하드웨어와의 성능 차이가 큼
  • Postgres, MariaDB, Percona 간의 성능 비교에 대한 질문이 있음
    • 각 데이터베이스가 어떤 경우에 뛰어난지 궁금해함
  • 더 많은 동시 연결을 허용하는 업데이트가 언제 출시될지에 대한 질문이 있음
    • pgbouncer 사용을 중단할 수 있기를 희망함
답변달기