まず、キャパシティ プランニングに関する標準的な質問をお読みください。
第二に、あなたはこれを間違って見ています。
メモリ (またはその他のリソース) の量は、設定する接続の数、必要な接続の数を決定するものではありません。 サーバーを購入する必要があるかどうかを決定します。
接続ごとのリソース要件は、マニュアルにかなり詳細に記載されており、リンク先の Wiki で説明されています。環境に何が必要かを把握し (または知識に基づいて推測し)、実行するハードウェアが何を投げかけるかを処理できることを確認してください。
具体的には、接続制限とプール サイズに関して、単一サーバー上またはプール/バウンサーを介して、アプリケーションの要件を満たす「十分な」接続が必要です。
「十分」は相対的な数です。1 つの接続を確立する (そして継続的に再利用する) アプリケーションは、1 つの接続のみを必要とします。ログインするエンドユーザーごとに接続を確立するアプリケーションには、ユーザーと同じ数の DB 接続が必要です。
Postgres と pgbouncer の両方のデフォルト値 デフォルトとして賢明です :
-
100 のデータベース接続は、Postgres を環境に投入する一般的な人にとっては多すぎます。
開発者はおそらく 10 個以上必要としないでしょう。他の誰もが数を増やすのに十分知っているでしょう。 -
pgbouncerから 20 件の接続 DB プールごとに、1 つのサーバーを指す 4 つのプールを取得でき、デフォルトの Postgres 接続制限を超えないことを意味します。
pgbouncerで複数のプールされたリソースを持つことが可能です 1 つのバックエンド データベースを指しており、バックエンド サーバーで利用可能な接続が常に必要です。
デフォルトの場合 それらを変更することが期待されている環境に適していません。
プールされた接続は、「利用可能なすべてのデータベース接続を常に結び付ける」という意味ではないことに注意してください。
pgbouncer のポイント あなたが指摘したように、再利用することです 接続。ここでの効率の向上には、利用可能なすべての接続を結び付ける必要はありません。単に切断、再接続、SSL の再ネゴシエーション、データベースへの再認証、接続セットアップ クエリの再実行を毎回行う必要はありません。