第9期鞭策:“最先进”的开源数据库上万连接就扛不动了,怪研发咯?

文中参考文档点击阅读原文打开, 同时推荐2个学习环境: 

1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》

2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》

3、PolarDB开源数据库内核、最佳实践等学习图谱:  https://www.aliyun.com/database/openpolardb/activity 

第9期吐槽:抓狂,最先进的开源数据库上万连接就扛不住了?

昨天刚刚鞭策PG短连接不行，第8期吐槽:高并发短连接性能怎么这么差? 万万没想到“高并发长连接”也不行！那怪研发咯？

1、产品的问题点

• 大量连接+大量写小事务 性能差

2、问题点背后涉及的技术原理

• PG判定事务可见性依赖事务快照, 结构为:ProcArray, 事务启动时、RC事务隔离级别的Statement执行开始时都要加ProcArray共享锁, 写操作的事务结束时需要加ProcArray排他锁. 高并发写操作发生时容易产生ProcArray排他锁冲突. 虽然procarray是有hash分区每次只锁映射的分区来降低排他锁冲突, 但是连接过多的情况下冲突依旧明显.

3、这个问题将影响哪些行业以及业务场景

• 读写频繁、高并发(大量连接, 通常指超过5000个连接)小事务的业务. 例如2C的SaaS类场景.

4、会导致什么问题?

• 高并发写操作发生时容易产生ProcArray排他锁冲突. 性能下降. 上万连接的高并发写操作性能可能降低到1000 tps以内.

5、业务上应该如何避免这个坑

• 使用连接池, 降低总连接数.

• 如果应用程序本身不具备连接池的能力, 使用pgbouncer这类中间连接池

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 管理更加复杂

• pgbouncer引入后, 必须是要statement或transaction level连接池, 从而无法使用prepared statement, 导致query parse,rewrite,plan的开销增加.

• 更新: 《pgbouncer 1.21 开始支持 prepared statement in 事务模式》

7、数据库未来产品迭代如何修复这个坑

• 内置线程连接池

• 对事务快照进行 CSN 或 CTS 改造

• https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/cts.md

• 内置连接池插件: https://github.com/nextgres/nextgres-idcp

• 使用PolarDB, 内置shared server, 可以抵挡上万高并发小事务性能不降. 参考github文章: 《开源PolarDB|PostgreSQL 应用开发者&DBA 公开课 - 5.5 PolarDB开源版本必学特性 - PolarDB 特性解读与体验》

• postgrespro也发表过内置连接池的功能, 参考github文章: 《PostgresPro buildin pool(内置连接池)版本 原理与测试》 而且这个patch 在9年之前的PG 9.6版本发布时就有提交, 可惜一直没有被社区接收, 又要再多加一条吐槽, 是谁在阻止好的功能合并入社区版本? 拉出来鞭尸一百遍.

文章中的参考文档请点击阅读原文获得. 

欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.  

近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: