作者：王志斌，曾獲得中國PostgreSQL數(shù)據(jù)庫管理工程師（PGCE），是PostgreSQL官方認證講師，盤古云課堂特邀金牌講師。
連接池選擇必須有測試數(shù)據(jù)作為支撐，才能更好來決定如何選擇。通過下面的測試結(jié)果，能夠更加直觀的看到兩者之間的差異（相關(guān)數(shù)據(jù)及測試結(jié)果來源自Percona[3]）：
一般來說，PostgreSQL通過將它的主要操作系統(tǒng)進程“分叉”到每個新連接的子進程中來實現(xiàn)連接處理。在操作系統(tǒng)級別上獲得了PostgreSQL中每個連接的資源利用率的完整視圖（以下輸出來自top命令）：
表1直連內(nèi)存占用情況
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)
首先，在時間和內(nèi)存方面，分叉一個操作系統(tǒng)進程要比為一個現(xiàn)有進程生成一個新線程要昂貴得多。隨著時間的推移，考慮變得越來越重要。這可能是為什么在基于PostgreSQL的應(yīng)用程序的擴展生命周期中早期就需要連接池機制的原因之一。
為了說明連接池可能對PostgreSQL服務(wù)器的性能產(chǎn)生的影響，利用在sysbench-tpcc上對PostgreSQL進行的測試，并通過使用PgBouncer作為連接池來部分重復(fù)了這些測試。
當(dāng)?shù)谝淮芜\行測試時，目標(biāo)是針對PostgreSQL的sysbench-tpcc工作負載優(yōu)化PostgreSQL，該工作負載運行56個并發(fā)客戶端（線程），并且服務(wù)器具有相同數(shù)量的可用CPU，運行時間定為30分鐘。這次的目標(biāo)是更改并發(fā)客戶端的數(shù)量（56、150、300和600），以查看服務(wù)器如何應(yīng)對連接的擴展。
使用事務(wù)池進行測試，因為sysbench-tpcc的工作量由幾個短語句和單語句事務(wù)組成。下表為完整使用的配置文件，命名為pgbouncer.ini：
表2pgbouncer.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：每個用戶/數(shù)據(jù)庫對允許多少個服務(wù)器連接。
max_client_conn：允許的最大客戶端連接數(shù)
userslist.txt通過指定文件AUTH_FILE只包含用于連接到PostgreSQL的用戶和口令的信息;該文件中的密碼可以是純文本密碼，也可以是使用MD5或SCRAM加密的密碼，具體取決于要使用的身份驗證方法。
定義用戶的另一種方法是讓PgBouncer在需要時直接查詢PostgreSQL后端。這是通過配置參數(shù)設(shè)置的auth_user，可以在全局或每個數(shù)據(jù)庫中設(shè)置。設(shè)置此選項后，PgBouncer使用該用戶連接到PostgreSQL后端，并運行該設(shè)置定義的查詢auth_query以查找用戶和密碼。如果auth_user本身需要用于該連接的密碼，則需要在user.txt中進行設(shè)置。關(guān)于相關(guān)細節(jié)請參見Pgbouncer官網(wǎng)。
使用以下命令將PgBouncer作為守護程序啟動：
$pgbouncer -d pgbouncer.ini
除了僅運行基準(zhǔn)測試30分鐘并每次更改并發(fā)線程數(shù)之外，線程數(shù)=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
對于使用連接池的測試，調(diào)整連接選項，以便與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
每次執(zhí)行sysbench-tpcc之后，使用以下命令清除操作系統(tǒng)緩存：
$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
在default_pool_size=56的情況下，結(jié)果如下：
sysbench-tpcc的TPS：比較與PostgreSQL的直接連接和將PgBouncer作為連接池
在只有56個并發(fā)客戶端的情況下運行sysbench-tpcc時，使用到PostgreSQL的直接連接可以提供比使用PgBouncer時高2.5倍的吞吐量（TPS表示每秒事務(wù)）。在這種情況下，使用連接池會極大地影響性能。在如此小的規(guī)模下，連接池沒有任何收益，只有開銷。
但是，當(dāng)使用150個并發(fā)客戶端運行基準(zhǔn)測試時，我們開始看到使用連接池的好處。顯然測試TPS值明顯高于直連方式。
即使并發(fā)客戶端數(shù)量增加一倍然后四倍，PgBouncer仍可以保持這樣的吞吐量，在這種情況下，所發(fā)生的是沒有立即充滿大量請求到服務(wù)器，而是全部停止在PgBouncer外面。一旦釋放了其池中的一個連接，PgBouncer僅允許下一個請求繼續(xù)進行到PostgreSQL。
該策略對于sysbench-tpcc似乎非常有效。對于其他工作負載，平衡點可能位于其他地方。
對于上述測試，在PgBouncer上將default_pool_size設(shè)置為等于此服務(wù)器上可用的CPU內(nèi)核數(shù)（56）。為了探索此參數(shù)的調(diào)整，我使用較大的連接池（150、300、600）和較小的連接池（14）重復(fù)了這些測試。結(jié)果如下：
PgBouncer的使用如何影響sysbench-tpcc的吞吐量：首先比較不同池大小的使用
使用較小的連接池（14），其大小僅為可用CPU數(shù)量的1/4，仍然產(chǎn)生幾乎相同的結(jié)果。說明充分利用PgBouncer進行連接處理已經(jīng)有開始有效果。
將連接池池中的連接數(shù)加倍并沒有任何實際的區(qū)別。但是一旦將該數(shù)字推斷為600，此時并發(fā)線程數(shù)大于可用CPU數(shù)，吞吐量就變得與不使用連接池時的吞吐量相當(dāng)。即使運行的并發(fā)線程數(shù)與池中可用的連接數(shù)（600）相同，也是這樣。可以預(yù)料的是在PostgreSQL有一個實際的限制。
首先，將連接池大小設(shè)置為等于服務(wù)器中可用CPU的數(shù)量，似乎是個好主意。大約有150個左右的連接池可能有一個硬限制。下表是針對不同視圖總結(jié)了獲得的結(jié)果的表格：
從上述的測試過程可以了解到，使用連接池可以充分提高數(shù)據(jù)庫的處理效率。
了解更多PostgreSQL熱點資訊、新聞動態(tài)、精彩活動，請訪問中國PostgreSQL官方網(wǎng)站
解決更多PostgreSQL相關(guān)知識、技術(shù)、工作問題，請訪問中國PostgreSQL官方問答社區(qū)
下載更多PostgreSQL相關(guān)資料、工具、插件問題，請訪問中國PostgreSQL官方下載網(wǎng)站
