V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
fanfever
V2EX  ›  数据库

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

  •  
  •   fanfever · 2018-01-10 12:08:29 +08:00 · 1110 次点击
    这是一个创建于 2270 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    7 条回复    2018-01-11 23:15:30 +08:00
    pmispig
        1
    pmispig  
       2018-01-10 16:32:32 +08:00
    你呀,还是图样,我呢,以前接了一个项目,都是外包做的,每个库 1000 连接,因为有 10 多个库,所以有 1 万多连接。当然,这个 mysql 是我搭建的,我索性改成了 6 万。后来上云了,好家伙,阿里云只支持 2000,程序歇菜了。
    支持几十万连接又不用做什么优化,改个参数重启就成。
    whx20202
        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
    fanfever
        3
    fanfever  
    OP
       2018-01-10 20:56:46 +08:00 via iPhone
    @pmispig 连接数过多难道不会造成 rds 的服务器频繁 cs ?反而降低吞吐?这也是文中所阐述的观点
    fanfever
        4
    fanfever  
    OP
       2018-01-10 21:04:34 +08:00 via iPhone
    @whx20202 文中没说不能支持多连接数,只是在实际压测并发时连接数较少能减少 cs 切换,增加吞吐,那我是否可以理解,在同一时刻所有应用进程的连接数总和也最好不要超过 2n+1
    whx20202
        5
    whx20202  
       2018-01-10 21:56:53 +08:00
    @fanfever cs 是什么?
    业务上,数据库侧,不要有有太多( 5000 )个连接,我在工作中经常遇到连接数太多,因为切换、争抢管道,spin lock 导致系统 load 很高。
    线程模型能好些,但是还是不建议太多。

    web 进程侧,最好就是 100 以内,很多都是 20 或者个位数的,因为你这个数据库可能很多实例都在连。
    fanfever
        6
    fanfever  
    OP
       2018-01-11 00:18:54 +08:00 via iPhone
    @whx20202 cs 是上下文切换
    pmispig
        7
    pmispig  
       2018-01-11 23:15:30 +08:00
    @fanfever 我的意思是配置了太多连接数的都是卢瑟,还有一个意思是服务端要支持很多连接数并不是什么问题,得益于 epoll 并不会消耗太多资源。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   4852 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 05:37 · PVG 13:37 · LAX 22:37 · JFK 01:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.