作者
digoal
日期
2021-12-20
标签
PostgreSQL , 热门问题
- 问题说明(现象、环境)
- 分析原因
- 结论和解决办法
4、为什么增加连接不能无限提高TPS或QPS? 配置多少个链接合适?
https://www.bilibili.com/video/BV1Lg411w7z4/
有时候, 我们可能会遇到这样的情况, 增加链接能提高数据库的TPS或QPS. 所以会带给我们一个假象, 好像要提高tps或qps, 只要增加连接就可以了, 真的是这样吗?
数据库请求过程大致可以简化为:
- 业务通过网络连接数据库,
- 提交SQL请求,
- 数据库处理SQL请求并返回结果.
- 从存储获取数据
- 存入shared buffer
- 非索引可能要逐条计算operator判断tuple是否where条件
- 有索引则分是bitmap还是index扫描, 或者分是不是losse索引, 要不要recheck.
- 期间可能还会有等待, 例如锁等待.
抛开等待的话, SQL请求耗费了哪些资源呢?
- 网络处理能力: 包转发能力pps、带宽(吞吐)、网络传输延迟RT.
- 数据库处理SQL请求可能用到: (都存在单次请求的 响应延迟, 整体请求处理吞吐 上限.)
- cpu(计算),
- 内存访问,
- 内存拷贝,
- 存储访问等.
提醒一下: 很多人可能会忽略 响应延迟(RT)、或者其他等待的间隙, 一个请求下去, 到等待请求返回, 这之间都有等待间隙.
其实我们的世界弥漫着响应延迟(RT), 如小到量子力学, 量子的跳变就是不连续的. 存在间隙. 世界并不是连续的.
https://www.jianshu.com/p/2ebb10f62a35
只有假设能量在传播的过程中，不是连续不断的，不存在无限小的单位，而是必须被分成一段、一段的，能量传播必须有一个最小单位，这个完美的公式及黑洞辐射的问题只有使用这种假设才能被解释的通，可一旦这个假设成立，那么便意味着由伽利略、牛顿所建立的经典力学的根基就要被动摇，因为在经典力学中，时间、空间、能量都是连续不断的，可以无限被分割的，普朗克的这个假设就意味着经典力学的根本就是错误的。
什么情况增加连接能提高qps、tps吞吐呢?
- 当网络、cpu、存储、内存等资源都没有达到其对应的上限时, 加连接可能提高tps、qps.
- 例如
- 1个请求RT是1毫秒. 那么1个链接每秒最多可以处理1000个请求.
- 如果网络吞吐、CPU资源、内存带宽、存储带宽都没有达到瓶颈. 理论上增加连接还能提高每秒的处理请求数.
那么配置多少个链接合适呢?
- 可以配置到: 资源耗尽的临界点 ~ 直到出现较大的性能下降(过了临界点后, 再继续增加连接, 性能会出现下降).
例如:
- 100和1000个链接都能把资源耗光, 那100个肯定比1000个好, 因为:
- 每个连接本身还会占用资源, 而且CPU核数有限, 切换cpu时间片也会带来额外的调度性能损耗.
- 100的整体处理能力通常比1000高. 这也是为什么我们做性能压测会发现连接数达到一定的时候, 性能不升反降.
但是也不是说就一定要配置100个, 因为有些时候这100个可能全是LONG SQL, 遇到短平快的SQL可能没有可用连接, 这个时候怎么办?
- 建议不同业务可用通过不同的用户或DB进行隔离, 不同的DB、用户配置不同的连接上限.
- 类似银行的VIP柜台, 普通柜台. 当普通用户柜台满了还有普通用户来银行办理业务时, VIP柜台就算空着也不给普通用户使用.
- 又或者是数据库内核能支持: 当VIP来了, 优先给他分配CPU资源, 让普通SQL处理进入等待.
配置多少个链接合适呢? 经验值:
1、对于OLTP系统, 如果网络是内网(没有跨网段), 网络RT比较低时. 使用pgbench压测TPC-B, 读性能峰值通常出现在2到4倍CPU核心数. 写性能峰值可能出现在1到2倍CPU核心数.
2、真实场景, 业务可能并不是不断的发起请求, 而且可能出现占着茅坑不拉屎的情况, 例如业务启动1个事务后, 发起1条SQL, 然后它要等业务自己的逻辑处理, 等个几分钟再发起下一波请求, 最后结束事务.
这样的情况, 就真的有可能加连接就能提高处理吞吐, 因为你可以理解为一个连接大量的时间处在空闲状态. 这样的情况连接要加到一定数量才能达到数据库的TPS QPS处理峰值.
最后: 要辩证的看待问题, 不能死板.
期望 PostgreSQL 增加什么功能?
PolarDB for PostgreSQL云原生分布式开源数据库
PostgreSQL 解决方案集合
德哥 / digoal's github - 公益是一辈子的事.
