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

> Clean Markdown view of GeekNews topic #20783. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20783](https://news.hada.io/topic?id=20783)
- GeekNews Markdown: [https://news.hada.io/topic/20783.md](https://news.hada.io/topic/20783.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-05-08T13:34:01+09:00
- Updated: 2025-05-08T13:34:01+09:00
- Original source: [pganalyze.com](https://pganalyze.com/blog/postgres-18-async-io)
- Points: 4
- Comments: 2

## Summary

Postgres 18은 **비동기 I/O**, **io_uring** 등 새로운 I/O 방식을 도입하여 클라우드 환경의 **디스크 읽기** 성능을 최대 2.8배까지 높입니다. `io_method`, `effective_io_concurrency` 등 **설정 파라미터**와 **pg_aios**와 같은 모니터링 도구가 추가되어 성능 분석과 튜닝 역량이 확대됩니다. 비동기화로 인해 기존 **EXPLAIN ANALYZE**의 I/O 타이밍 해석이 어려워지며, `pg_aios`를 통한 실시간 비동기 요청 정보 확인이 가능합니다. Postgres 18은 클라우드에서의 **고지연 디스크** 대응에 중점을 두고 있으며, 차기 버전에서 **비동기 쓰기 지원**도 예정되어 있습니다.

## Topic Body

- 현재 베타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` 뷰를 통해 현재 진행 중인 비동기 요청의 상세 정보 확인 가능  
  ```sql  
  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에서는 **비동기 쓰기 지원**도 기대됨

## Comments



### Comment 38370

- Author: jujumilk3
- Created: 2025-05-09T09:45:39+09:00
- Points: 1

포스트그레 진짜 최고 짱

### Comment 38346

- Author: neo
- Created: 2025-05-08T13:34:02+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43916577) 
- 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 사용을 중단할 수 있기를 희망함