
了解更多Greenplum相关内容,欢迎访问Greenplum中文社区网站
在《Pgbouncer最佳实践》系列的第一篇 概念篇 中,我们介绍了数据库连接池在Pgbouncer中的三种方式。为什么使用连接池,使用与不使用之间的性能差异,以及连接池模式的工作流程、细节及一些注意事项等内容。
今天作者将继续为大家介绍Pgbouncer带来的性能提升的相关测试。
连接池选择必须有测试数据作为支撑,才能更好来决定如何选择。通过下面的测试结果,能够更加直观的看到两者之间的差异(相关数据及测试结果来源自Percona[3]):
一般来说,PostgreSQL通过将它的主要操作系统进程“分叉”到每个新连接的子进程中来实现连接处理。在操作系统级别上获得了PostgreSQL中每个连接的资源利用率的完整视图(以下输出来自top命令):
表 1 直连内存占用情况
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND24379 postgres 20 0 346m 148m 122m R 61.7 7.4 0:46.36 postgres: sysbench sysbench ::1(40120)24381 postgres 20 0 346m 143m 119m R 62.7 7.1 0:46.14 postgres: sysbench sysbench ::1(40124)24380 postgres 20 0 338m 137m 121m R 57.7 6.8 0:46.04 postgres: sysbench sysbench ::1(40122)24382 p

本文详述了Pgbouncer作为数据库连接池在PostgreSQL性能提升方面的测试。通过对比直接连接与使用Pgbouncer的TPS,展示了在并发客户端增加时,连接池如何有效地管理请求,提高吞吐量。测试表明,连接池大小设置为服务器CPU数量相当时效果最佳,而在超过一定阈值后,性能可能会下降。此外,文章还提到了在Greenplum中使用Pgbouncer的性能提升。
最低0.47元/天 解锁文章
463

被折叠的 条评论
为什么被折叠?



