数据库连接池设置为进程数*2+1 于现有云厂商 RDS 最大连接数不一致的疑惑。

[fanfever]

按照 https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing 这篇文章所说 将线程池数量设置为 connections = ((core_count * 2) + effective_spindle_count)是最佳实践， 但是包括 aliyun 的 rds 在内，1cpu1G 的 RDS 的连接数都能支撑 2000 左右，是这些云厂商的 RDS 做了特殊优化么？ 那么这块的设置到底应该以哪个为准？ 另外文章的第二段说从应用层尽量减少获取连接的次数，这个应该如何实施较好？ 是减少事务的粒度，尽快归还连接？

[pmispig]

你呀，还是图样，我呢，以前接了一个项目，都是外包做的，每个库 1000 连接，因为有 10 多个库，所以有 1 万多连接。当然，这个 mysql 是我搭建的，我索性改成了 6 万。后来上云了，好家伙，阿里云只支持 2000，程序歇菜了。
支持几十万连接又不用做什么优化，改个参数重启就成。

[whx20202]

我这上 github 突然卡了，我就随便说一下
1. mysql 可能还好，pgsql 的链接是进程模型，如果说服务端有很多链接，哪怕是 idle 的，都会使得系统的 load average 变成灾难一般
2. 另外我觉得 2000 连接是没问题的，具体概念有：
链接池：数据库的 client，也就是你的 web 服务器，代码内存里，管理的链接
数据库端线程池： 这个比较特别，经常因为用得不对出问题，是数据库端管理的连接池
数据库的最大连接数： 就是你说的 2000

一般来说，连接池，都设置的比较小，比如 6 个。
因为你有多个 worker，多个虚拟机跑同样的代码，所以 6 * worker 数 * 虚拟机数目
这个数目最好不要超过 2000

[fanfever]

@pmispig 连接数过多难道不会造成 rds 的服务器频繁 cs ？反而降低吞吐？这也是文中所阐述的观点

[fanfever]

@whx20202 文中没说不能支持多连接数，只是在实际压测并发时连接数较少能减少 cs 切换，增加吞吐，那我是否可以理解，在同一时刻所有应用进程的连接数总和也最好不要超过 2n+1

[whx20202]

@fanfever cs 是什么？
业务上，数据库侧，不要有有太多（ 5000 ）个连接，我在工作中经常遇到连接数太多，因为切换、争抢管道，spin lock 导致系统 load 很高。
线程模型能好些，但是还是不建议太多。

web 进程侧，最好就是 100 以内，很多都是 20 或者个位数的，因为你这个数据库可能很多实例都在连。

[fanfever]

@whx20202 cs 是上下文切换

[pmispig]

@fanfever 我的意思是配置了太多连接数的都是卢瑟，还有一个意思是服务端要支持很多连接数并不是什么问题，得益于 epoll 并不会消耗太多资源。