注目★★★★★Hacker News
PgBouncer を 16 プロセス化し 4 倍のスループット達成—単一スレッド制約を so_reuseport で突破
30秒で把握
- 1PgBouncer を 16 プロセス並列化・so_reuseport でカーネル負荷分散・スループット 87k → 336k トランザクション/秒に 4 倍向上
- 2単一プロセスは 1 コア 97% CPU 使用・16vCPU マシン全体 10% 利用に対し、16 プロセス構成は 8 コア活用・52% 利用率達成
- 3プロセス間 peering でクエリキャンセルを正確化・接続バジェット分割で Postgres 過剰接続防止・ClickHouse Managed Postgres で標準構成化
要約
ClickHouse Managed Postgres は単一スレッドの PgBouncer を複数プロセスで並列化し、スループットを約 4 倍 (87k → 336k トランザクション/秒) に向上させた。カーネルの so_reuseport で同一ポートに複数プロセスをバインドし、入力接続を負荷分散する一方、クエリキャンセルはプロセス間の peering で正しいセッション所有者へ転送する。接続バジェット (max_client_conn / max_db_connections) をプロセス数で分割し、Postgres への過剰接続を防ぐ。同一スペック 16vCPU インスタンスで単一プロセスは 1 コアに張り付き全体は 10% 利用率に対し、16 プロセス構成は 8 コアを活用して 52% 利用率に達する。
あなたへの影響
自社で PostgreSQL コネクションプール構成を運用している場合、PgBouncer が単体ではマルチコア活用できない制約が顕在化する可能性があります。
推奨：本記事の so_reuseport + peering パターンは汎用的な構成なため、スケーリング計画段階で検証対象に加えることを推奨します。