[PostgreSQL] Asynchronous I/O

#PostgreSQL

Postgresql 18 버전부터는 기존의 틀을 깨고, 비동기식 I/O를 전면 도입하는 최적화가 들어간다.

기존에는 동기 방식의 I/O를 사용해서만 파일이나 네트워크 통신을 했었다고 한다. 그래도 성능이 충분히 괜찮았던게 신기하다.

아무튼 18 버전부터는 비동기 I/O가 기본 동작이 된다. 그리고 I/O 방식을 파라미터로 조절할 수도 있다.

I/O 조절 옵션: io_method

상기했듯이, pg 18에서는 io_method라는 파라미터로 I/O 방식을 조절할 수 있다
그 옵션은 다음과 같다.

기본 동작은 io_method=worker다. 자체적인 백그라운드 워커를 몇개 두고서 직접 스케줄링하는 것이다.

흥미로운 부분은 성능이 우월하다고 주장하는 io_uring이 자체 구현 worker보다 처리량이 저조할 때가 많다는 것이다. 그래서 이건 지금 시점에서는 사용하기에 적절하지 않다.

실제 성능 벤치마크를 보면, work I/O가 sync I/O보다 2배 정도 빠르기도 하다.

당연히 sync가 제일 느리고, io_uring이 중간 지점의 성능을 보여준다.
그리고 worker가 가장 빠른건 확실한데, 워커 개수를 어떻게 잡느냐에 따라서 폭이 좀 생긴다. 너무 적게 잡으면 느려진다.

그리고 내가 예전에 만들어놨던 벤치마크가 있어서 그거에도 적용해봤는데, 엄청 크진 않지만 유의미한 성능 향상이 있었다. 17 vs 18이고, 1000만개의 KV 데이터를 빠르게 우겨넣는 APPEND 벤치마크였다.

확실히 처리량이 늘긴 늘고, 레이턴시 측면에서도 좀 더 빨라진 것 같다.

이제는 기본 동작이 worker I/O로 바뀌기 때문에 워커 수를 조정하는 것도 튜닝포인트가 된다. 파라미터는 io_workers.

아직 실험 데이터가 충분하진 않아서 딱 뭐라 짚어서 추천하기도 어렵고, pg가 자동으로 하드웨어 최적값을 세팅해주지도 않는다.

확실한 것은 적은 것보다는 많은게 좋은데, 코어 수보다는 같거나 적어야 한다는 것이다.
대체로는 코어 개수의 25% 정도를 워커 개수로 잡고 보는 것을 고려해볼만하다. 그 이상은 테스트가 필요하다. 코어 개수로 맞추는 것도 이론적으로는 괜찮다.

io_method를 통한 비동기/동기 선택 기능은 아직 모든 부분에 적용되진 않는다.

대표적인 예외는 인덱스 스캔 부분이다. 추후에 반영될 수도 있으나, 지금은 아니다.