概要
- PgBouncer は シングルスレッド 設計によるCPU利用の制限
- so_reuseport と プロセスフリート でCPUコアを有効活用
- Peering でキャンセルリクエストの問題を解決
- 実験結果 でスループットとリソース利用率の大幅向上を確認
- ClickHouse Managed Postgres はこの構成を標準採用
PgBouncerのシングルスレッド制限とその回避策
- PgBouncer は1プロセスで 1コア のみ利用、残りコアは未使用
- 16 vCPUのマシンでは 1コアのみ がプーリング処理担当
- so_reuseport を活用し、複数プロセスが同一ポートで待機
- カーネルが 着信接続 を各プロセスに 自動分散
- クライアントからは 単一エンドポイント に見える
- プロセスごとにシングルスレッド、so_reuseportで 全コア活用
Peeringによるキャンセルリクエスト対応
- Postgresのキャンセルリクエストは 新規接続 で送信
- so_reuseport利用時、 別プロセス にリクエストが届く可能性
- Peering 導入でプロセス間の 協調 実現
- 間違ったプロセスに届いたキャンセルも 正しいプロセスへ転送
- フリート全体で キャンセル処理 が機能
コネクションプール・リソース管理
- トランザクションモード でプール運用
- トランザクション終了時に 即座にコネクション返却
- コネクション上限(max_client_conn, max_db_connections) は
- プロセス数で 均等分割
- フリート全体で Postgresの過負荷防止
実験と性能比較
- 16 vCPU c7i.4xlarge で検証
- 1プロセス構成と16プロセス構成で比較
- クライアント数: 8〜256でスループットとCPU利用率を測定
- 1プロセス構成 ：最大約87,000 TPSで頭打ち、256クライアント時は77,000 TPSに低下
- CPU利用率 は1コア分(約97%)、全体では10%未満
- 16プロセス構成 ：最大約336,000 TPS、8コア分を利用
- CPU利用率 は約52%、Postgresやロードジェネレータがボトルネックになるまで余力あり
- CloudWatch でも同様の傾向
- 1プロセス: 平均16% CPU利用
- 16プロセス: 平均60% CPU利用
コネクション上限とスループットの違い
- 1プロセス は自身のmax_client_conn超過で新規接続拒否
- フリート構成 は上限を分散しつつ、 全体で高い接続数 を実現
適用と推奨構成
- 少数接続時は 1プロセス でも十分
- 高並列時は フリート構成 が圧倒的に有利
- ClickHouse Managed Postgres は標準でこの構成を採用
- Postgresプロビジョン時 に自動的に有効
まとめ
- PgBouncer の シングルスレッド制限 はso_reuseportとプロセスフリートで解消
- Peering でキャンセルリクエストも正しく処理
- 高並列・高負荷環境 では フリート構成 が必須
- ClickHouse Managed Postgres で最適なコネクションプーリング環境を実現