PG空閑連接對(duì)性能的影響

該系列的第一篇為:PG空閑連接的資源消耗討論P(yáng)G如何管理連接以及空閑連接如何消耗內(nèi)存和CPU。本文討論空閑連接對(duì)PG性能的影響。

事務(wù)率影響

PG獲取數(shù)據(jù)的時(shí)候,首先看請(qǐng)求頁(yè)在沒(méi)在共享內(nèi)存。如果共享內(nèi)存沒(méi)有請(qǐng)求頁(yè),則從操作系統(tǒng)緩存取,如果也沒(méi)有,則需要請(qǐng)求磁盤(pán)上的數(shù)據(jù)頁(yè)。共享內(nèi)存最快,操作系統(tǒng)緩存次之,磁盤(pán)最慢。隨著PG連接的增長(zhǎng),操作系統(tǒng)緩存的可用內(nèi)存就會(huì)減小,從而從操作系統(tǒng)緩存中移除數(shù)據(jù)頁(yè)。下次再進(jìn)行數(shù)據(jù)頁(yè)查詢(xún)時(shí)就會(huì)從磁盤(pán)上請(qǐng)求,因此性能變得更慢。

如果PG實(shí)例的空閑內(nèi)存處于低水位,就會(huì)使用swap。這也是位于磁盤(pán)上,因此也很慢。使用swap空間可幫助釋放一些內(nèi)存,但是如果swapped 頁(yè)再次被OS請(qǐng)求時(shí),會(huì)被讀回,導(dǎo)致IO的增加。更多信息請(qǐng)查看swap管理:https://www．kernel．org/doc/gorman/html/understand/understand014．html

可用內(nèi)存對(duì)性能的影響取決于工作負(fù)載、數(shù)據(jù)集、總共的可用內(nèi)存。如果數(shù)據(jù)集比總可用內(nèi)存小,空閑內(nèi)存的減少不會(huì)有明顯影響,若數(shù)據(jù)集比總可用內(nèi)存還大,就會(huì)產(chǎn)生巨大影響。

性能測(cè)試

下面小節(jié)顯示了通過(guò)pgbench進(jìn)行的性能測(cè)試。測(cè)試中Amazon RDS for PG實(shí)例為db．m5．large,2vCPU,8GB內(nèi)存。1個(gè)EBS的IO為3000IOPS。

每個(gè)測(cè)試都有兩個(gè)階段,第一階段pgbench執(zhí)行1個(gè)小時(shí),沒(méi)有其他工作負(fù)載。這個(gè)提供了一個(gè)基準(zhǔn)事務(wù)率。

第二個(gè)階段,再次執(zhí)行pgbench前打開(kāi)1000個(gè)連接,每個(gè)連接從information_schema表獲取一行數(shù)據(jù)。下面是步驟:

1)打開(kāi)一個(gè)連接

2)獲取所有表名及information_schema視圖:

 SELECT table_schema||'．'||table_name as relname from information_schema．tables WHERE table_schema='information_schema';

3)循環(huán)執(zhí)行select:

 SELECT * FROM information_schema．columns LIMIT 1;

4)對(duì)于1000個(gè)連接重復(fù)以上步驟

5)事務(wù)提交后不進(jìn)行斷開(kāi),保持空閑狀態(tài)

重啟實(shí)例后,內(nèi)存中沒(méi)有緩存任何數(shù)據(jù)頁(yè)。第一次執(zhí)行pgbench會(huì)加載請(qǐng)求的數(shù)據(jù)頁(yè)到內(nèi)存,隨后再次執(zhí)行pgbench,cache中的數(shù)據(jù)頁(yè)可以重用,此時(shí)不再需要從磁盤(pán)加載。

為了最小化頁(yè)緩存的影響,在執(zhí)行測(cè)試案例前執(zhí)行一個(gè)初始步驟。下圖顯示了打開(kāi)1000個(gè)連接時(shí),實(shí)例內(nèi)存時(shí)如何從4．88GB下降到90MB的。

正如前系列介紹,雖然連接是空閑的,他們也會(huì)消耗內(nèi)存和CPU資源。這個(gè)結(jié)果顯示空閑連接對(duì)性能的影響。

事務(wù)率測(cè)試1:標(biāo)準(zhǔn)pgbench

第一個(gè)測(cè)試中,使用標(biāo)準(zhǔn)配置執(zhí)行100個(gè)客戶(hù)端連接,結(jié)果:

transaction type:

1000個(gè)連接下,結(jié)果:

transaction type:

結(jié)果表明,TPS從1249下降到1140,有8．7%的下降。

事務(wù)率測(cè)試2:select-only

因?yàn)榭臻e連接消耗了內(nèi)存減小了頁(yè)緩存可用內(nèi)存,所以這些空閑連接對(duì)讀的影響尤為明顯。為測(cè)試這點(diǎn),使用-S配置運(yùn)行pgbench,使用內(nèi)置的select only腳本。結(jié)果:

transaction type:

1000個(gè)空閑連接下:

transaction type:

TPS從1969下降到1610,有18．2%的下降。

事務(wù)率測(cè)試3:custom pgbench

執(zhí)行腳本:

set nbranches :scaleset naccounts 100000 * :scaleset aid random(1, :naccounts)set bid random(1, :nbranches)BEGIN;SELECT * FROM pgbench_accounts WHERE aid >= :aid AND aid < (:aid + 5000) AND bid=:bid LIMIT 1;END;

腳本中每個(gè)事物從pgbench_accounts表讀取5000行數(shù)據(jù),然后僅返回1條。結(jié)果:

transaction type: pgbench_script．sqlscaling factor: 5000query mode: simplenumber of clients: 100number of threads: 2duration: 600 snumber of transactions actually processed: 227484latency average = 264．140 mstps = 378．586790 (including connections establishing)tps = 378．592772 (excluding connections establishing)

1000個(gè)空閑連接下,結(jié)果為:

transaction type: pgbench_script．sqlscaling factor: 5000query mode: simplenumber of clients: 100number of threads: 2duration: 600 snumber of transactions actually processed: 124114latency average = 484．485 mstps = 206．404854 (including connections establishing)tps = 206．507645 (excluding connections establishing)

結(jié)果顯示TPS從378下降到206,有46%的下降。通過(guò)Amazon RDS Performance Insights可以看到引擎wait events詳細(xì)信息。下面兩個(gè)圖顯示了DataFileRead等待事件中耗費(fèi)時(shí)間最多的。即等待從表數(shù)據(jù)文件中讀取數(shù)據(jù)。

下圖顯示了Amazon CloudWatch指標(biāo)中的讀負(fù)載:

第一次執(zhí)行時(shí)讀為87MB/s,第二次1000個(gè)連接下,增長(zhǎng)到117MB/s。空閑連接消耗了操作系統(tǒng)內(nèi)存,導(dǎo)致OS cache變小。因此需要從磁盤(pán)讀取更多數(shù)據(jù)頁(yè),從而導(dǎo)致性能的衰減。

連接池

連接池可幫助減小數(shù)據(jù)庫(kù)連接帶來(lái)的影響�？梢允褂胮gbouncer或者Amazon RDS Proxy。這些連接池可以限制連接數(shù)量。

Pgbouncer

Pgbouncer是輕量級(jí)的連接池組件,支持下面三種模式:

Session mode:每個(gè)應(yīng)用連接綁定到一個(gè)數(shù)據(jù)庫(kù)連接上。如果連接處于空閑狀態(tài),pgbouncer不能將它給其他應(yīng)用連接重用。

Transaction mode:一個(gè)事務(wù)完成后,該連接就可以重用

Statement mode:一個(gè)SQL語(yǔ)句完成后就可以將該連接給其他客戶(hù)端重用。

大多數(shù)應(yīng)用中,使用transaction mode可以提供最優(yōu)結(jié)果。下面測(cè)試pgbouncer配置了最大5000客戶(hù)端連接,但我們的測(cè)試中最大連接設(shè)置為200．pgbench運(yùn)行在pgbouncer pool中。結(jié)果:

transaction type: pgbench_script．sqlscaling factor: 5000query mode: simplenumber of clients: 100number of threads: 2duration: 600 snumber of transactions actually processed: 227064latency average = 264．600 mstps = 377．928241 (including connections establishing)tps = 377．928476 (excluding connections establishing)

運(yùn)行過(guò)程中,可以查看連接狀態(tài):

pgbouncer=# show pools;-[ RECORD 1 ]-----------database   | pgbenchuser       | postgrescl_active  | 100cl_waiting | 0sv_active  | 100sv_idle    | 0sv_used    | 0sv_tested  | 0sv_login   | 0maxwait    | 0maxwait_us | 0pool_mode  | transaction

Pool狀態(tài)顯示有100個(gè)客戶(hù)端連接(cl_active)從而有100個(gè)活躍server連接(sv_active)。第二次執(zhí)行,打開(kāi)1000個(gè)連接,并處于空閑狀態(tài)。Pooler不需要維護(hù)任何服務(wù)端連接:

pgbouncer=# show pools;-[ RECORD 1 ]-----------database   | pgbenchuser       | postgrescl_active  | 1000cl_waiting | 0sv_active  | 0sv_idle    | 1sv_used    | 0sv_tested  | 0sv_login   | 0maxwait    | 0maxwait_us | 0pool_mode  | transaction

1000個(gè)空閑連接下,執(zhí)行pgbench:

transaction type: pgbench_script．sqlscaling factor: 5000query mode: simplenumber of clients: 100number of threads: 2duration: 600 snumber of transactions actually processed: 226827latency average = 264．935 mstps = 377．451418 (including connections establishing)tps = 377．451655 (excluding connections establishing)

下面顯示使用連接池是,性能沒(méi)有影響:

pgbouncer=# show pools;-[ RECORD 1 ]-----------database   | pgbenchuser       | postgrescl_active  | 1100cl_waiting | 0sv_active  | 100sv_idle    | 0sv_used    | 0sv_tested  | 0sv_login   | 0maxwait    | 0maxwait_us | 0pool_mode  | transaction

總共有1100個(gè)客戶(hù)端連接,但是僅有100個(gè)服務(wù)端連接活躍。

該測(cè)試,RDS實(shí)例有2個(gè)CPU,因此100個(gè)進(jìn)程并行執(zhí)行,導(dǎo)致大量上下文切換,從而造成性能衰減。Pgbouncer配置最多20個(gè)數(shù)據(jù)連接下性能:

transaction type: pgbench_script．sqlscaling factor: 5000query mode: simplenumber of clients: 100number of threads: 2duration: 600 snumber of transactions actually processed: 256267latency average = 234．286 mstps = 426．828543 (including connections establishing)tps = 426．828801 (excluding connections establishing)

得到了個(gè)更高的TPS,狀態(tài):

pgbouncer=# show pools;-[ RECORD 1 ]-----------database   | pgbenchuser       | postgrescl_active  | 20cl_waiting | 80sv_active  | 20sv_idle    | 0sv_used    | 0sv_tested  | 0sv_login   | 0maxwait    | 0maxwait_us | 125884pool_mode  | transaction

只有20個(gè)客戶(hù)端連接活躍。剩下的80個(gè)連接等待被分配。更多的連接并不意味著更多的吞吐量。較少的客戶(hù)端連接有助于上下文切換和資源爭(zhēng)用,從而提高總體性能。

總結(jié)

連接數(shù)多并不意味著高吞吐。增加連接數(shù),會(huì)增加上下文切換和資源爭(zhēng)用,從而影響性能。

PG連接即使空閑狀態(tài),也會(huì)消耗資源。空閑連接不會(huì)影響性能的假設(shè)不正確。

應(yīng)用設(shè)計(jì)的時(shí)候需要考慮不要有太多連接。