昨天一个微信群里在讨论一个数据库连接数的计算公式，截图看不太清楚。我来描述一下。说是PG提供了一个连接数计算公式：连接数=核心数*2+有效磁盘数量。其中核心数不应该包含超线程数量，而是物理核的数量。
这是一个十分典型的极限测试估算连接数的公式，主要目的是规避CPU方面存在的瓶颈。这种设置思路往往不会使用在普通的生产系统上，因为不管是OLTP系统还是OLAP系统，作为数据库服务器来说，会话会有大量的工作会产生在IO上，包括网络IO和磁盘IO，真正使用CPU的比例实际上并不高。对于OLTP系统来说大量的CPU使用都是小于一个时间片（大部分UNIX系统都是一个厘秒）的，很少会把一个时间片用满，因为数据库应用中，会话大部分都在等待某些等待事件，比如IO，LWLOCK，LOCK,IPC等，一个会话ONCPU状态的比例很低，因此使用CPU数量来作为会话数的设置基础实际上并没有任何科学依据。
从另外一个角度来说，CPU之间也是有差异的，哪怕核数相同的CPU，其处理能力也不能同日而语，三五年前的同样核数的CPU，其处理能力可能不到现在的1/3，花费同样CPU时间能够完成的任务也会相差极大。简单的用CPU作为设置连接数的依据显然是不合理的。在现在的绝大多数OLTP系统中，数据库服务器的CPU资源都是十分充足的，大部分系统的主要问题并不出现在CPU资源不足上，这是这二十年来摩尔定律给我们带来的红利。
实际上数据库中的存在排队效应的地方很多，任何一个地方存在瓶颈都会影响极限测试的性能，也会影响到生产环境中的并发访问效率。两年前我写过一篇文章《从疏通下水道联想到的优化问题》，这篇文章中对此做了详细的分析，有兴趣的朋友可以在我的公众号中查找阅读。
实际上决定数据库连接数的最主要因素还是应用，对于绝大多数数据库系统而言，max_connections参数一定要确保使用这个数据库的所有模块不会因为连接池不足而导致应用报错。现在的应用系统大多十分复杂，还有大量的模块使用并发量十分不稳定的微服务。我见过一套数据库系统对接的应用连接池超过100个，哪怕一个连接池设置几十个连接，max_connections也必须设置为几千才能确保大多数情况下不会因为数据库连接数限制而导致应用故障。
数据库的最大连接数设置的过大有什么坏处呢？最容易出问题的往往不是CPU，当然如果在云环境中，我们给数据库的CPU资源很少，那么较大的连接可能会引发CPU资源的不足。关于云环境数据库服务器的CPU资源问题，那是一个更大的话题-容量管理，今天我们暂不讨论。数据库应用对CPU的使用一般来说是不存在资源不足的问题的，当然如果某个并发量很大的SQL的执行计划错了，是很容易把CPU跑爆掉的，这个也不在我们今天探讨的范围内，因为这种情况出现，哪怕连接数设置的很低，也会出问题。
除此之外，实际上最容易出问题的是内存，数据库会话数多了，因为ATTACH共享内存所占用的TLB就会很大，特别是数据库没有使用大页的情况下。前阵子我们在分析一个数据库宕机的案例中，就发现一台128GB的数据库服务器上，TLB居然高达30GB。另外会话都会使用WORK_MEM来做排序、JOIN等操作。会话数多了，这些内存自然就会使用的更多。前两年和一个国外的PGER交流的时候，他提出了一个PG内存估算的方法，悲观的算法是MAX_CONNECTIONS*WORK_MEM作为会话工作内存，乐观的算法是MAX_ACTIVE_SESSIONS*WORK_MEM作为会话的工作内存。根据这个，结合物理内存大小，计算SHARED_BUFFERS能够使用内存的最大值。
实际上悲观与乐观算法算出来的值相差甚大，基本上不具备参考意义。当时我和他说与其这么精打细算，莫不如把SWAP设置大一点，哪怕物理内存偶尔用的多一些，系统产生一个小抖动，很快就能挺过去了。他想了一会儿，认同了我的观点。
实际上我们今天讨论的内容很多都属于容量管理的范畴，这个问题也是困扰了我近20年的问题，这20年里，参与过不少容量管理相关的项目，也帮用户构建了一些模型，只不过，感觉还是在门外晃悠。等有时间，我也会写几篇这方面的文章，把我们这些年的一些成果分享给大家。
