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工做。

本文僅表明做者我的觀點，與官方無關。