Pgbouncer最佳实践 之 性能提高篇

了解更多Greenplum技术干货，欢迎访问Greenplum中文社区网站

在《Pgbouncer最佳实践》系列的第一篇 概念篇 中，咱们介绍了数据库链接池在Pgbouncer中的三种方式。为何使用链接池，使用与不使用之间的性能差别，以及链接池模式的工做流程、细节及一些注意事项等内容。

今天做者将继续为你们介绍Pgbouncer带来的性能提高的相关测试。

链接池选择必须有测试数据做为支撑，才能更好来决定如何选择。经过下面的测试结果，可以更加直观的看到二者之间的差别（相关数据及测试结果来源自Percona[3]）：

通常来讲，PostgreSQL经过将它的主要操做系统进程“分叉”到每一个新链接的子进程中来实现链接处理。在操做系统级别上得到了PostgreSQL中每一个链接的资源利用率的完整视图（如下输出来自top命令）：

表 1 直连内存占用状况

PID USER      PR NI VIRT RES  SHR S %CPU %MEM TIME+  COMMAND             
24379 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 postgres  20 0 338m 129m 115m R 57.4  6.5 0:46.09 postgres: sysbench sysbench ::1(40126)

首先，在时间和内存方面，分叉一个操做系统进程要比为一个现有进程生成一个新线程要昂贵得多。随着时间的推移，考虑变得愈来愈重要。这多是为何在基于PostgreSQL的应用程序的扩展生命周期中早期就须要链接池机制的缘由之一。

为了说明链接池可能对PostgreSQL服务器的性能产生的影响，利用在sysbench-tpcc上对PostgreSQL进行的测试，并经过使用PgBouncer做为链接池来部分重复了这些测试。

当第一次运行测试时，目标是针对PostgreSQL的sysbench-tpcc工做负载优化PostgreSQL，该工做负载运行56个并发客户端（线程），而且服务器具备相同数量的可用CPU，运行时间定为30分钟。此次的目标是更改并发客户端的数量（5六、150、300和600），以查看服务器如何应对链接的扩展。

使用事务池进行测试，由于sysbench-tpcc的工做量由几个短语句和单语句事务组成。下表为完整使用的配置文件，命名为pgbouncer.ini：

表 2 pgbouncer.ini文件

[databases]
sbtest = host=127.0.0.1 port=5432 dbname=sbtest
 
[pgbouncer]
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = userslist.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = postgres
pool_mode = transaction
default_pool_size=56
max_client_conn=600

除了pool_mode之外，其余最重要的变量是：

• default_pool_size：每一个用户/数据库对容许多少个服务器链接。
• max_client_conn：容许的最大客户端链接数

userslist.txt经过指定文件AUTH_FILE只包含用于链接到PostgreSQL的用户和口令的信息;该文件中的密码能够是纯文本密码，也能够是使用MD5或SCRAM加密的密码，具体取决于要使用的身份验证方法。

定义用户的另外一种方法是让PgBouncer在须要时直接查询PostgreSQL后端。这是经过配置参数设置的auth_user，能够在全局或每一个数据库中设置。设置此选项后，PgBouncer使用该用户链接到PostgreSQL后端，并运行该设置定义的查询auth_query以查找用户和密码。若是auth_user自己须要用于该链接的密码，则须要在user.txt中进行设置。关于相关细节请参见Pgbouncer官网。

使用如下命令将PgBouncer做为守护程序启动：

$pgbouncer -d pgbouncer.ini

除了仅运行基准测试30分钟并每次更改并发线程数以外，线程数=56。下面的示例来自第一次运行：

$ ./tpcc.lua --pgsql-user=postgres --pgsql-db=sbtest --time=1800 --threads=56 --report-interval=1 --tables=10 --scale=100 --use_fk=0  --trx_level=RC --pgsql-password=****** --db-driver=pgsql run > /var/lib/postgresql/Nando/56t.txt

对于使用链接池的测试，调整链接选项，以便与PgBouncer而不是PostgreSQL直接链接。请注意，它仍然是本地链接：

./tpcc.lua --pgsql-user=postgres --pgsql-db=sbtest --time=1800 --threads=56 --report-interval=1 --tables=10 --scale=100 --use_fk=0  --trx_level=RC --pgsql-password=****** --pgsql-port=6543 --db-driver=pgsql run > /var/lib/postgresql/Nando/P056t.txt

每次执行sysbench-tpcc以后，使用如下命令清除操做系统缓存：

$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'

在default_pool_size=56的状况下，结果以下：

图 3 链接池相同测试结果

sysbench-tpcc的TPS：比较与PostgreSQL的直接链接和将PgBouncer做为链接池

在只有56个并发客户端的状况下运行sysbench-tpcc时，使用到PostgreSQL的直接链接能够提供比使用PgBouncer时高2.5倍的吞吐量（TPS表示每秒事务）。在这种状况下，使用链接池会极大地影响性能。在如此小的规模下，链接池没有任何收益，只有开销。

可是，当使用150个并发客户端运行基准测试时，咱们开始看到使用链接池的好处。显然测试TPS值明显高于直连方式。

即便并发客户端数量增长一倍而后四倍，PgBouncer仍能够保持这样的吞吐量，在这种状况下，所发生的是没有当即充满大量请求到服务器，而是所有中止在PgBouncer外面。一旦释放了其池中的一个链接，PgBouncer仅容许下一个请求继续进行到PostgreSQL。

该策略对于sysbench-tpcc彷佛很是有效。对于其余工做负载，平衡点可能位于其余地方。

对于上述测试，在PgBouncer上将default_pool_size设置为等于此服务器上可用的CPU内核数（56）。为了探索此参数的调整，我使用较大的链接池（150、300、600）和较小的链接池（14）重复了这些测试。结果以下：

图 4 链接池不一样测试结果

PgBouncer的使用如何影响sysbench-tpcc的吞吐量：首先比较不一样池大小的使用

使用较小的链接池（14），其大小仅为可用CPU数量的1/4，仍然产生几乎相同的结果。说明充分利用PgBouncer进行链接处理已经有开始有效果。

将链接池池中的链接数加倍并无任何实际的区别。可是一旦将该数字推断为600，此时并发线程数大于可用CPU数，吞吐量就变得与不使用链接池时的吞吐量至关。即便运行的并发线程数与池中可用的链接数（600）相同，也是这样。能够预料的是在PostgreSQL有一个实际的限制。

首先，将链接池大小设置为等于服务器中可用CPU的数量，彷佛是个好主意。大约有150个左右的链接池可能有一个硬限制。下表是针对不一样视图总结了得到的结果的表格：

图 5 测试汇总结果

为了测试一下Pgbouncer在Greenplum中带来的性能提高，咱们在Greenplum中也作了一轮测试，测试结果以下：

图 6 Greenplum测试汇总结果

上表是Greenplum 使用Pgbench 作性能测试时直连master节点和使用Pgbouncer的性能对比。

• Greenplum cluster 的配置: 一个master 节点，两个segments ，每一个节点独占一个虚拟机: 32 CPU, 32G 内存
• Pgbench 初始化命令：

pgbench -i -s 1000 pgbench

Pgbench数据库大小:14G；

• Pgbench 测试命令：

  pgbench -c $N -j $N -r -T 60 -P 1 -b select-only  -C  pgbench

  “-C" 每一个事务使用新的链接，N是并发数量。

从上述的测试过程能够了解到，使用链接池能够充分提升数据库的处理效率。

做者简介：

原文做者：王志斌，曾得到中国PostgreSQL数据库管理工程师（PGCE），是PostgreSQL官方认证讲师，盘古云课堂特邀金牌讲师。

Greenplum相关内容丰富：王晓冉，现任Greenplum研发工程师。研究生毕业于中国科学院软件所软件工程专业。目前主要负责gpcopy的研发工做。此前参与了gpkakfa的研发及Postgres Merge工做。

本文仅表明做者我的观点，与官方无关。