如何理解連接池推薦（（2 * n_cores）+ n_disks）和支持100個連接之間的PostgreSQL差異？
來自 PostgreSQL 文件：
為了獲得最佳吞吐量，活動連接的數量應該接近 ((core_count * 2) + Effective_spindle_count)
一般來說，好的硬體上的 PostgreSQL 可以支持幾百個連接。
對我來說——不是一個經驗豐富的 DBA——這裡的某個地方存在差異，尤其是在查看一些 DB 即服務提供商的產品時。
例如，此時 Amazon RDS 最大的機器 (db.r3.8xlarge) 有 32 個 vCPU，根據第一個公式，在給定許多磁碟的情況下，池中的 100 個連接可能會設法以最佳方式執行。第二個公式中的“幾百個連接”不是很糟糕嗎？
更極端的是另一家 DBaaS 提供商的差異，他們提出了一個具有 500 個並發連接的 2 核伺服器。這怎麼可能運作良好？
如果我有什麼誤解，請告訴我。非常感謝！
“可以支持”！=“最佳吞吐量”。
您可以使用大量連接，但速度較慢。
如果您使用更少的連接和排隊工作，您可以在更短的時間內完成相同數量的工作。
更極端的是另一家 DBaaS 提供商的差異，他們提出了一個具有 500 個並發連接的 2 核伺服器。這怎麼可能運作良好？
他們要麼在事務池模式下使用像 PgBouncer 這樣的連接池前端，要麼無法正常工作。
人們喜歡大數字，所以他們會給你大數字。
他們這樣做實際上是在損害性能。PostgreSQL 有一些成本與 線性擴展
max_connections，因此*即使不使用連接，*它仍然會對性能產生影響。此外，即使是空閒連接也會產生一些額外的內務管理成本。
如果連接正在積極工作，那麼您還會爭用系統資源和內部鎖。
我經常遇到遇到 PostgreSQL 性能問題的人——他們試圖通過在應用程序中添加更多連接、更多工作人員等來解決這些問題。尤其是執行排隊系統的人。很難說服他們減少工人數量會使系統執行得更快，而他們最初的性能問題源於工人數量過多。