- 現在ベータ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(*) を実行
コールドキャッシュ性能比較：
| バージョン/設定 |
実行時間（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では非同期書き込み対応も期待される
2件のコメント
Postgres は本当に最高、超すごい
Hacker Newsの意見
preadv2(..., RWF_NOWAIT)を使ってページキャッシュから非同期読み取りを実行できる。これはio_method = workerでレイテンシを下げるのに役立つ可能性があるNOWAIT読み取りを試し、失敗した場合にのみワーカースレッドへオフロードする方法が提案されているaio(4)には多くの作業が行われており、Linux/glibc aioの欠点がない点から、その動作の仕組みは興味深いだろうという意見io_uringのセキュリティ問題への懸念があり、多くのLinux管理者やディストリビューションがこれを無効化しているのかという質問があるVACUUM ANALYZEジョブなどが含まれるpgbouncerの利用をやめられることを期待している