接続プールの推奨（（2 * n_cores）+ n_disks）と数百の接続のサポートの間のPostgreSQLの不一致を理解するにはどうすればよいですか？
PostgreSQLのドキュメントから：
データベース接続の数->最適なデータベース接続プールサイズを見つける方法
最適なスループットを得るには、アクティブな接続の数が（（core_count * 2）+ effective_spindle_count）の近くにある必要があります
PostgreSQLサーバーのチューニング-> max_connections
一般に、優れたハードウェア上のPostgreSQLは数百の接続をサポートできます。
私（経験豊富なDBAではありません）のどこかに、特にいくつかのDB-as-a-Serviceプロバイダーの提供に注目すると、矛盾が生じます。
たとえば、現時点では、Amazon RDSの最大のマシン（db.r3.8xlarge）には32個のvCPUがあり、最初の式によれば、多くのディスクが与えられた場合、プール内の100接続で最適に実行できます。 2番目の式からの「数百の接続」では非常にひどく実行されませんか？
さらに極端なのは、500の同時接続を持つ2コアサーバーを提案する別のDBaaSプロバイダーの不一致です。これはどうやってうまくいくのでしょうか？
誤解している場合はお知らせください。どうもありがとう！
「サポート可能」！=「最適なスループット」。
多数の接続を使用できますが、低速です。
使用する接続とキューの作業が少ないほど、同じ時間でより少ない量の作業を実行できます。
さらに極端なのは、500の同時接続を持つ2コアサーバーを提案する別のDBaaSプロバイダーの不一致です。これはどうやってうまくいくのでしょうか？
トランザクションプーリングモードでPgBouncerのような接続プーリングフロントエンドを使用しているか、うまく機能しません。
しかし、人々は大きな数を好むので、彼らはあなたに大きな数を与えるでしょう。
そうすることで実際にパフォーマンスが低下しています。 PostgreSQLには、max_connections、つまり接続が使用されていない場合でもそれでもパフォーマンスに影響があります。
さらに、アイドル接続であっても、いくつかのハウスキーピングコストがかかります。
接続がアクティブに機能している場合は、システムリソースと内部ロックにも競合があります。
私は定期的にPostgreSQLのパフォーマンスの問題を抱えている人々に出くわします-そして、より多くの接続、アプリケーション内のより多くのワーカーなどを追加することによってそれらを解決しようとします。特にキューイングシステムを実行している人々。 低下ワーカー数がシステムを稼働させる高速であり、元々のパフォーマンスの問題はそもそも数が多すぎることが原因であると説得するのは驚くほど難しいです。
多くのアプリケーションは接続規律が不十分であり、使用されていないときでも接続を開いたままにします。
接続制限を高く設定することは、これらのアプリケーションに対する安価な保険です。何かが変更され、アプリケーションがそれらすべての接続をアクティブに使用することを決定するまで、保険はかなり高額になります。
質問で比較された2つのクレームを区別する重要な違いは、最初のものは、一度にactive接続数の大まかな定式化であることです。 2番目の主張は、Postgresが受け入れることができる最大許容値を設定するためのものです。これらは2つに分かれています。
戻って最適なデータベース接続プールサイズの記事を読むと、サーバー側ではなく、クライアント側でアクティブな接続プールを設定するように提案されていることがわかります。また、ハンズオンクライアントアクティビティや管理アクティビティなどの固定接続に対応するために、max_connections値に十分な容量を残すことをお勧めします。あなたしないでください max_connectionsをワーカーのアクティブな接続制限に設定する必要があります。そうしないと、必要なときにpsqlを実行できない場合があります。