PostgreSQL Pgbouncer 到底怎么使用,疗效有多大

接上期为什么postgresql 需要连接池的问题过后, 本期还是要说说pgbouncer 连接池,并且需要做一个实验看看pgbouncer 到底在处理并发连接到底有多大的功效.

Pgbouncer 安装比较简单,直接下载编译,

$ ./configure --prefix=/usr/local/pgbouncer
$ make
$ make install

安装很简单,问题是如何使用pgbouncer 才能达到相关的需求以及pgbouncer 到底能提供什么给我们什么,首先PG定义为轻量级的数据库连接池产品,另外PG中有三种连接方式,这是主要需要关注的点.

上图是客户连接到语句执行的一个过程,其中的questions是问题点,其中不少session 都有长时间的 idle的状态,而这个状态导致,此时如果需要连接,就需要建立新的进程,来访问数据库,那么连接数就上来了. 而使用pgbouncer的主要原因, 1 将多个connnections 对数据库的访问进行复用,也就是减少 session的idle的状态, 2 如果连接不够用,则在pgbouncer 会将暂时无法分配的连接至于等待的状态,待有idle 空闲的进程,则进行安排.

如果要用大白话来说,没有使用pgbouncer的连接方式是私家车,如果车子太多,则路就塞满了,而使用了pgbouncer 的方式则类似公交车或小巴, 有人上车有人下车,座位是固定的,所以公交车如果本身有30个座位,但实际上在整个的路途中可不是仅仅支持30个人,至于支持了多少人,那就看连接到数据库的事务执行的快慢,是否能对一个连接进行复用, 这就有点CPU 的分时使用的概念.

下面针对pgbouncer 的方式不同,处理连接的角度不同

1 session pooling  这里是针对session来说的,当用户的连接的任务完成结束后,pgbouncer 将连接进行相关的复用,这样的设置本身和程序的连接池的意义基本上一致.

2 Transaction pooling 这里对于连接的概念中的单位变为了transaction 也就是一个连接的通道分时的使用, 这样的好处比上面的session pooling 对比要明显的多,连接的使用率会跟随相关的分配有更高的复用,和性能方面的提高.

3 Statement pooling  这里针对的是语句的方式进行划分,虽然性能上可能是优,但针对PG运行事务的方式,则大部分场景不合适.

Session pooling  
Most polite method. When client connects, a server connection will be assigned to it for the whole duration the client stays connected. When the client disconnects, the server connection will be put back into the pool. This is the default method.

Transaction pooling
A server connection is assigned to client only during a transaction. When PgBouncer notices that transaction is over, the server connection will be put back into the pool.

Statement pooling  
Most aggressive method. The server connection will be put back into pool immediately after a query completes. Multi-statement transactions are disallowed in this mode as they would break.

所以今天我们的整体的测试也是在前两种模式中进行查看性能差距的,而不是后者.

那么我们就围绕着上面的选择项来进行相关的测试

系统配置如下

Postgresql 本身 max connection  为 10000 (一万,当然这对于任何数据库都很过分) ,使用程序模拟3000个并发连接,当前在程序连接到PG后,整体的数据库状态在2017稳定下来,但整体机器已经变得响应比较迟缓.

那我们在换transaction pooling 的方式来进行测试, 我们将相关的

同样的情况pgbouncer 本身 default pools 为200 ,PG的连接数始终在201,并且3000个连接并发查询并未报错.

并且和刚才不使用pgbouncer之间的区别在直观的系统资源使用的感官上并未因为使用了很大连接数,而造成系统的响应变慢的情况.

那我们继续将pgbouncer 的提供的处理方式该为session pooling 

实际上结果和上面是基本相同的,但在程序端就不一样了,

这个是transaction 

这个是session 

基本上瞬间使用transaction的结果,基本上所有的连接都已经完成接入和数据库进行数据的查询, 而session 则只能接受213个连接,上面已经讲过相关的原理, 这里是要用这个演示来证明, 我们在使用pgbouncer的情况下,应该的是transaction 而不是session否则基本上大部分环节下(于业务以及相关设计以有关),session并不能帮助你做什么特别大的改变,大部分连接处于等待的状态.