Postgres 18을 기다리며: 비동기 I/O로 디스크 읽기 속도 향상
Postgres 18을 기다리며: 비동기 I/O로 디스크 읽기 속도 향상 | GeekNews
MySQL InnoDB에선 어떻게 비동기 I/O를 처리했을까 → [0517] **MySQL(InnoDB)**에서의 비동기 I/O
PostgreSQL은 오랜 기간 동안 동기적(블로킹) I/O 모델을 기반으로 디스크 데이터를 처리해 왔습니다. 이 모델은 간결하고 예측 가능한 동작을 보장하지만, 특히 지연(latency)이 큰 클라우드 환경에서는 성능 병목의 주요 원인이 되기도 합니다.
블로킹 I/O(blocking I/O)란, 프로세스가 디스크에서 데이터를 읽을 때 해당 작업이 완료될 때까지 기다리는 방식을 의미합니다. PostgreSQL에서는 쿼리가 디스크 블록을 필요로 할 때, 해당 블록이 shared buffer에 없다면 OS로부터 데이터를 가져올 때까지 쿼리 수행이 일시 중단됩니다. 이 대기 시간 동안 해당 프로세스는 다른 작업을 수행하지 못하고 CPU 자원을 비효율적으로 사용하게 됩니다.
Postgres는 데이터를 직접 디스크에서 읽기보다는, 먼저 shared buffer pool을 확인하고, 필요할 경우 OS 페이지 캐시를 거쳐 디스크로 접근합니다. 이 과정은 일반적으로 다음 단계를 따릅니다:
read() 시스템 호출을 통해 OS 페이지 캐시 또는 디스크에서 블록 로드전통적인 블로킹 I/O 방식은 로컬 디스크나 빠른 NVMe SSD 환경에서는 상대적으로 성능 문제가 적지만, AWS EBS와 같은 네트워크 기반 스토리지를 사용할 경우, I/O 대기 시간이 수 밀리초 이상으로 늘어나며 전체 쿼리 성능에 큰 영향을 미칩니다.
또한, 동시에 여러 개의 블록을 읽어야 하는 쿼리의 경우, 각 I/O 요청이 순차적으로 처리되므로 디스크 I/O 병렬화가 불가능하며, 이는 고성능 처리 요구가 있는 상황에서 처리량 한계를 초래합니다.