是否存在什么规则或东西可以用来计算 和 的max_connections合适default_pool_size数字max_client_conn？
默认值很奇怪。PostgreSQL 默认为 max_connections=100，而 pgbouncer 默认为 default_pool_size=20。default_pool_size 难道不应该总是高于 max_connections 吗？否则，有什么意义呢？我以为 pgbouncer 旨在通过降低开销（通过重用 PostgreSQL 的连接）让我们处理更多连接。我很困惑。
我正在寻找类似于PostgreSQL 的维基，例如“此参数应占内存的~50％”。
我记得 MySQL 有一个电子表格可以让你计算这类参数。如果 PostgreSQL/pgbouncer 有类似的东西就太棒了。
答案1
首先，阅读我们关于容量规划的典型问题。
您所要求的具体建议是容量规划建议，您必须针对您的特定环境自行制定该建议。
其次，你的看法是错误的。
你拥有的内存（或任何其他资源）的数量并不决定你设置的连接数，你需要决定了你必须购买的服务器有多强大。
每个连接的资源要求如下手册非常详细，并在您链接的 Wiki 上进行了讨论。弄清楚您的环境需要什么（或做出有根据的猜测），并确保您要运行的硬件可以处理您要处理的内容。
具体来说：连接限制和池大小，您应该有“足够”的连接来满足您的应用程序的要求 - 无论是在单个服务器上还是通过池/保镖。
“足够”是一个相对数字：建立（并不断重用）一个连接的应用程序只需要一个连接。为每个登录的最终用户建立连接的应用程序需要的数据库连接数与用户数相同。
Postgres 和的默认值pgbouncer如下：默认值：
对于将 Postgres 投入环境的普通人来说，100 个数据库连接已经很多了。
开发人员可能不需要超过 10 个。其他人都知道增加这个数字的必要性。每个数据库池20 个连接
pgbouncer意味着您可以让 4 个池指向一台服务器，而不会超出默认的 Postgres 连接限制。可以有
多个池资源pgbouncer指向一个后端数据库，并且您总是希望后端服务器上有一些可用的连接。
如果默认值不适合您的环境，您需要更改它们。
请记住，池化连接并不意味着“始终占用所有可用的数据库连接”。正如您所指出的
，其目的pgbouncer是重复使用连接。此处的效率提升并不需要您绑定每个可用连接，而只需要您不必每次都断开连接、重新连接、重新协商 SSL、重新验证数据库身份并重新运行连接设置查询。
答案2
每个用户/数据库对允许多少个服务器连接。
因此，如果默认配置是池大小为 20，总共 100 个连接，这意味着 5 个不同的用户/数据库对在达到总体限制之前必须各自达到池大小的最大值。相反，如果您使用 pgbouncer 通过单个用户路由到单个数据库，则您的有效连接限制为 20，而不是 100，因此您必须相应地为该用例设置池大小。YMMV。