按照 https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing 这篇文章所说 将线程池数量设置为 connections = ((core_count * 2) + effective_spindle_count)是最佳实践, 但是包括 aliyun 的 rds 在内,1cpu1G 的 RDS 的连接数都能支撑 2000 左右,是这些云厂商的 RDS 做了特殊优化么? 那么这块的设置到底应该以哪个为准? 另外文章的第二段说从应用层尽量减少获取连接的次数,这个应该如何实施较好? 是减少事务的粒度,尽快归还连接?
1
pmispig 2018-01-10 16:32:32 +08:00
你呀,还是图样,我呢,以前接了一个项目,都是外包做的,每个库 1000 连接,因为有 10 多个库,所以有 1 万多连接。当然,这个 mysql 是我搭建的,我索性改成了 6 万。后来上云了,好家伙,阿里云只支持 2000,程序歇菜了。
支持几十万连接又不用做什么优化,改个参数重启就成。 |
2
whx20202 2018-01-10 17:28:13 +08:00
我这上 github 突然卡了,我就随便说一下
1. mysql 可能还好,pgsql 的链接是进程模型,如果说服务端有很多链接,哪怕是 idle 的,都会使得系统的 load average 变成灾难一般 2. 另外我觉得 2000 连接是没问题的,具体概念有: 链接池:数据库的 client,也就是你的 web 服务器,代码内存里,管理的链接 数据库端线程池: 这个比较特别,经常因为用得不对出问题,是数据库端管理的连接池 数据库的最大连接数: 就是你说的 2000 一般来说,连接池,都设置的比较小,比如 6 个。 因为你有多个 worker,多个虚拟机跑同样的代码,所以 6 * worker 数 * 虚拟机数目 这个数目最好不要超过 2000 |
3
fanfever OP @pmispig 连接数过多难道不会造成 rds 的服务器频繁 cs ?反而降低吞吐?这也是文中所阐述的观点
|
4
fanfever OP @whx20202 文中没说不能支持多连接数,只是在实际压测并发时连接数较少能减少 cs 切换,增加吞吐,那我是否可以理解,在同一时刻所有应用进程的连接数总和也最好不要超过 2n+1
|