段落引用原文作者： Hans-Jürgen Schönig
翻译：Tracy
原文链接：https://www.cybertec-postgresql.com/en/max_connections-performance-impacts
众所周知，将max_connections设置为非常高的值对性能来说并不是太好。几代系统管理员都遵循这个规则。只是出于好奇，我想试试看，在PostgreSQL中设置max_connections的真实影响。
我们再次使用相同的硬件进行测试：8 个4Ghz的AMD内核、16GB内存、Ubuntu12.04以及三星840 SSD。
测试前，我们使用 pgbench 创建了一个简单的测试环境。比例因子设置为100，也就是我们使用1000,0000 行的数据进行测试。共享缓冲区设置为2GB。
测试 1：活动连接
在第一个测试中，我们对max_connections使用了各种设置————但是，我们保持实际打开的数据库连接数不变。在我们的例子中，我们发起8个只读连接运行20分钟：
pgbench -S -j $CONNS -M prepared -T $T $DB -c $CONNS
结果相当稳定。即使在postgresql.conf中大幅增加 max_connections，PostgreSQL的性能曲线也是完全平坦的。这是有些意料之中的。
每秒事务数保持恒定在150,000/秒（读取）。那么，将max_connections设置为低值有什么意义呢？
测试 2：空闲连接
在下一个测试中，我们要稍微修改一下测试设置。我们再次使用了 8 个运行 pgbench 的工作连接，就像以前一样。但是，为了让 PostgreSQL 变得更糟，我们用空闲连接填充了剩余的连接。为此，我们创建了在后台运行 pg_sleep() 的数据库连接。简而言之：在 1024个连接测试的情况下，我们有8个活动连接和1016个执行SELECT pg_sleep()的连接（= 活动但空闲）。
在这种情况下，结果开始变得有趣。我们获得的连接越多，我们的TPS计数就越低。虽然下降幅度并不大，但仍然是稳定的，在结果中可以清楚地观察到：
有空闲连接的情况（8个活动连接）：
hs@chantal:~/benchmark$ ./run.sh 2> /dev/null 32：tps = 131706.112 128：tps = 130875.520 256：tps = 127894.491 512：tps = 127413.512 1024：tps = 126034.739 2048：tps = 125077.974
测试 3：更多负载……
现在让我们开启32个活动连接重复同样的测试，看看在给定更多连接的情况下吞吐量的变化是否恒定。
结果如下：
32：tps = 155681.582 128：tps = 153041.9681 256：tps = 151295.710 512：tps = 147398.063 1024：tps = 139920.943 2048：tps = 133637.017
我们在这里看到的是大幅下降（百分比）。这有点重要，因为系统负载越多，在这种情况下的影响就越大。
总而言之，我们必须指出 max_connections 本身并不是导致问题的原因。更多的是许多空闲连接和许多活动连接的组合引起的性能下降。
