Postgres max_connections (プーラーなし)

Postgres は接続に軽量スレッド プールを使用しません。クライアント接続ごとに、本格的なシステム プロセスがトリガーされます。

postmaster プロセスは、接続が試行されるたびに新しいプロセス (「フォーク」) を作成し、セッションが終了するまでこの単一セッション専用になります。公式プロジェクトのドキュメントでは、アーキテクチャの基礎に関する章でこのメカニズムが正確に説明されています (postgresql.org/docs/current/connect-estab.htmlの「接続セマンティクス」セクション、2026 年 8 月 24 日にアクセス)。

この選択には大きな利点があります。1 つの接続でクラッシュしても他の接続には影響せず、各プロセスはサーバーの残りの部分から分離されます。また、直接的なコストもかかります。接続が追加されるたびに、OS プロセス全体がスケジュールに追加され、独自のメモリ空間とカーネルのコンテキスト スイッチング オーバーヘッドが発生します。

2 つの異なるメカニズムが記憶に影響を及ぼし、それらを混同するとほとんどの場合誤診につながります。

1つ目は修正されています。 Postgres は起動時に、これらの接続がその後開かれるかどうかに関係なく、max_connections の値に応じたサイズの共有メモリ構造 (ロック、プロセス テーブル) を予約します。この設定の公式ドキュメントでは、この設定を増やすと、OS のデフォルト構成で許可されているよりも多くのシステム共有メモリが必要になる可能性があると明示的に指摘されています (postgresql.org/docs/current/runtime-config-connection.html、2026 年 8 月 24 日にアクセス)。

2 つ目は可変であり、大規模になるとさらに危険です。work_mem は接続ごとに 1 回割り当てられるのではなく、クエリ プランの並べ替えまたはハッシュ操作ごとに 1 回割り当てられます。この点については、公式ドキュメントで明示されています。複雑なクエリではこれらの操作のいくつかを並行して起動でき、複数のセッションで同じことを同時に行うことができるため、実際に使用されるメモリは work_mem の数倍の価値がある可能性があります (postgresql.org/docs/current/runtime-config-resource.html、2026 年 8 月 24 日にアクセス)。

公式 PostgreSQL プロジェクト Wiki には、開いている接続の合計数ではなく、ハードウェアが並行して効率的に処理できるアクティブな 接続 の数を計算するためのベンチマーク式が文書化されています (wiki.postgresql.org/wiki/Number_Of_Database_Connections、2026 年 8 月 24 日にアクセス)。

8 つの物理コアと SSD ストレージを備えたサーバーでは、式により、スループットが低下し始めるまでに、(8 × 2) + 1 = 17 のアクティブな接続が得られます。この数字はしばしば驚くべきものであり、アプリケーションが実際に開く数百の接続に比べれば、非常に小さいように見えます。これはまさに次の段落の主題です。

式によって計算される数値は、アプリケーションが開く必要があるクライアント接続の数ではなく、CPU とディスクが吸収できる同時実行性を測定します。 20 個のアプリケーション プロセスからなるフリートは、それぞれが 10 個の接続の独自のプールを持ち、たとえ特定の時点でアクティブに動作しているのが 17 個だけであっても、Postgres への同時接続を 200 個開きます。プーラーがない場合、max_connections は 17 ではなく 200 をカバーする必要があります。このギャップこそが、たとえどれを選択することになるとしても、ほとんどのアーキテクチャーで プーラーをトランザクション モードに追加することを促すのです (の PgBouncer、Supavisor、および PgCat の比較を参照してください)。

max_connections はホットスワップされません。これは postmaster コンテキスト パラメータです。Postgres は起動時にこれを 1 回読み取り、共有メモリのサイズを設定します。構成のリロード (pg_reload_conf() または SIGHUP) だけでは十分ではないため、サーバーを再起動する必要があります。

まず現在の値とそのコンテキストをチェックして、再起動が必要かどうかを確認します。

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- context='postmaster' は再起動が必要であることを確認します

次に、新しい値を適用して、再起動します。

ALTER SYSTEM SET max_connections = '300';

-- postgresql.auto.conf に記述されます。
-- Postgres が再起動されるまで効果はありません。

# systemdを使用した場合
sudo systemctl restart postgresql

# systemd を使用せず、pg_ctl を直接使用
pg_ctl restart -D $PGDATA -m fast

max_connections のサイズ設定は、単なる理論的な作業ではありません。 Aurabase が管理対象 Postgres クラスターに予算を割り当てる方法は次のとおりです。

専用クラスター: プロジェクトごとに 1 つの Postgres クラスター

このレベルでは (専用と共有ベースのの比較を参照)、各プロジェクトは、インスタンスのサイズに合わせてサイズ設定された独自の CloudNativePG クラスターと独自の max_connections バジェットを受け取ります。

共有クラスター: 組織の複数のプロジェクト、共有予算

この 2 番目のパスでは、同じ組織のすべてのプロジェクトが、共有プライマリの前にある CNPG プーラー (PgBouncer、transactionモード) を介して接続します。

組織内のすべてのプロジェクトは、共有アプリケーション ロールを通じて接続します。 したがって、max_user_connections だけで、このロールがクラスター全体で開くことができるサーバー接続の合計に上限が設定されます。これは、プーラー自体へのクライアント接続のみを制限する max_client_connではなく、実際のクラスター全体の安全策です。

ただし、このプーラーは SDK アプリケーション トラフィックのみを処理します。 PostgREST に関しては、プライマリ (-rwサービス) に直接接続されたままになります。トランザクション モードでプールすると、 pgrstという名前の専用 LISTEN チャネルをリッスンするスキーマ リロード メカニズムが壊れます。したがって、独自の接続 (共有レベルのレプリカごとに 2、専用レベルのレプリカごとに 10) は、プーラーの外部でプライマリの max_connections バジェットに直接カウントされます。これは、まさに、以下の手順のステップ 1 で含める必要がある種類の「忘れられた」接続です。

この手順は特定のツールには依存しません。管理対象または自己ホスト型の任意の Postgres サーバーに適用されます。

1. 実際のクライアント接続をカウントします。 アプリケーション プロセスの数に内部プールのサイズを掛けたものに、管理ツール、レプリケーション、監視を加えたもの。 max_connections の下限を設定するのは、式ではなくこの数値です。
2. PostgreSQL wiki の式 (物理コア × 2) + 効率的なディスクを使用して、ハードウェアの理想的な同時実行性 を計算します。この図は、スループットを低下させることなく、これらの接続のうち実際にいくつが並行して動作できるかを示しています。
3. max_connections を手順 1 で実際に必要な値よりも大きく設定し、superuser_reserved_connections およびアプリケーションの外部で独自の接続を開く管理ツール用に余裕を持たせます。
4. ALTER SYSTEM SET を使用して変更を適用し、サーバーを再起動します。 これはポストマスター パラメータです。上で詳しく説明したように、単純なリロードでは十分ではありません。
5. pg_stat_activity を経時的に監視します。 アイドル状態の接続の数がアクティブな接続の数を大幅に超えている場合、これは max_connections の問題ではありません。これは、より大きな数ではなく、サーバーの前にプーラーが必要であることを示しています。

ステップ 5 のモニタリング リクエストは、直接使用できます。

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

max_connections だけでは十分ではなくなった場合、その値に関係なく、体系的に 3 つのシグナルが返されます。

1. FATAL: sorry, too many clients already エラーはピーク負荷時に表示されますが、pg_stat_activity によって表示される接続の大部分はアイドル状態です。
2. アプリケーションはサーバーレス環境または一時的なワーカー (エッジ機能、短いジョブ) で実行され、Postgres の接続ごとのプロセス モデルが対応できるように設計されているよりもはるかに高速に接続を開いたり閉じたりします。
3. 上記の式と手順はすでに適用されており、クライアント接続の実際の必要性は、work_mem やshared_buffers を危険にさらすことなく利用可能なメモリが割り当てることができる量を超え続けています。

これら 3 つのケースでは、ほとんどの場合、正しい答えは、より高い max_connections ではなく、アプリケーションと Postgres の間に位置するプーラーです。 の PgBouncer、Supavisor、および PgCat の比較 では 3 つのオプションについて詳しく説明しており、トランザクション モードの ガイド では、プーラーが導入された後の最も一般的な妥協について説明しています。接続以外のすべての Postgres チューニングについては、 実稼働 Postgres チューニング チェックリストを参照してください。