PostgreSQL為什么接受大量連接到數(shù)據(jù)庫需要連接池

這篇文章將為大家詳細(xì)講解有關(guān)PostgreSQL為什么接受大量連接到數(shù)據(jù)庫需要連接池，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

PostgreSQL 是非常好的開源的數(shù)據(jù)庫,針對替換ORACLE數(shù)據(jù)庫的重任,基本上大部分中小型企業(yè),能指望的也只有POSTGRESQL ,當(dāng)然如果你愿意花更多的前,更多的應(yīng)用程序結(jié)構(gòu)方面的改造,MYSQL 也不是不可以, ORACLE 換成PG 就如同,你從一個中單的一個房間 換到另一個房間, 如果要是ORACLE 到MYSQL ,就如同你從北京,搬到上海. 所以如果不想大動干戈, 并且不想改變現(xiàn)有的整體架構(gòu), PG 一定是必然的選擇,沒有其他.

那在使用PG的時候,可能很快就會體會到PG之美, 與功能強(qiáng)大,這里就不在多說,今天要說的是,POSTGRESQL 在高并發(fā)下,超高連接對PG的沖擊,以及為什么PG 在高并發(fā)連接中,需要使用pgbouncer或pgpool 來.

首先就要祭出原理, 到底連接分配的內(nèi)存要從哪里來出,大部分人包括我,認(rèn)為,導(dǎo)致PG 無法接受大量連接的主要原因,其實是內(nèi)存. 由于大量的連接使用了大量的內(nèi)存,導(dǎo)致,PG 在接受大量的connections 會導(dǎo)致, OOM, 或者性能低下.

但實際上我們做一個測試,我對一個有用8G 內(nèi)存的 PG  ,加載3000個并發(fā)連接并且查詢一個表,同時將 shared_buffers 調(diào)整成20MB ,然后我就等待著PG崩潰.

實際上我并沒有如愿, PG 還是穩(wěn)穩(wěn)的運行, 但系統(tǒng)有一點緩慢,有點卡的感覺

內(nèi)存方面

也并沒有像我與預(yù)期的會徹底的用光.

那么問題來了, 到底各種 大小廣而告之,中提到的PG 不適宜 多連接的原因在哪里.

那就的從 PG 的源碼中的 PGPROC 說了, 

其中上面的each backend has a PGPROC struct in shared memory , + 后面的那句, 應(yīng)該表明 backend  和  shared memory 之間 存在一個pgproc的結(jié)構(gòu), 這個結(jié)構(gòu)的主要作用就是 復(fù)用.

后面的NOTE 的twophase.c 證明了PGPROC 結(jié)構(gòu)的復(fù)用,因為當(dāng)前的transaction 在隊列中 有兩個狀態(tài), 真正運行和準(zhǔn)備運行.

這個PGPROC 會在 PROC_HDR中被調(diào)用, allProcs 是一個指針,也就是所有的PGPROC 都會在這里面.PGPROC 主要的作用是要在事務(wù)處理期間處理相關(guān)例如等待和處理等工作之間的切換,PROC 主要的作用進(jìn)程間協(xié)同和通訊以及postmaster的跟蹤

而為了獲取這些信息的變化對share_buffer 和 backend  的臨時數(shù)據(jù)進(jìn)行獲取,他會遍歷到其他的process 中, 而如果我們建立的backend越多, 也就是連接到PG的連接越多, 就會導(dǎo)致遍歷GetSnapshotData 的工作消耗更多的系統(tǒng)資源,例如CPU.

由于查詢是最簡單的 select 語句,并且應(yīng)該也應(yīng)用到了緩存,IO性能基本上處于沒有使用的狀態(tài)

內(nèi)存的使用也未占滿.

多連接并不是通過內(nèi)存的消耗,將PG 帶入到OOM 和系統(tǒng)無響應(yīng)的情況中, 而是隨著backend變多后,內(nèi)部溝通的成本太高,導(dǎo)致性能上的問題,所以PG的在多連接中,是需要使用PGPOOL 或者 pgbouncer 之類的緩沖池來保證系統(tǒng)的性能,另外還有一個問題就是為什么要有這么多的連接, 這就是一個問題. 

那既然知道了PG在處理超多的連接上會有性能的問題，那如何解決這個問題對大多數(shù)使用的人就有相關(guān)的意義，可以帶著這個問題來問幾個問題

內(nèi)存的使用也未占滿.

多連接并不是通過內(nèi)存的消耗,將PG 帶入到OOM 和系統(tǒng)無響應(yīng)的情況中, 而是隨著backend變多后,內(nèi)部溝通的成本太高,導(dǎo)致性能上的問題,所以PG的在多連接中,是需要使用PGPOOL 或者 pgbouncer 之類的緩沖池來保證系統(tǒng)的性能,另外還有一個問題就是為什么要有這么多的連接, 這就是一個問題. 

那既然知道了PG在處理超多的連接上會有性能的問題，那如何解決這個問題對大多數(shù)使用的人就有相關(guān)的意義，可以帶著這個問題來問幾個問題。

1 為什么要有并發(fā)有那么多的連接， 例如一個數(shù)據(jù)庫要承受3000+以上的連接數(shù)，即使是互聯(lián)網(wǎng)屬性，整體的架構(gòu)設(shè)計是什么，如果并發(fā)的連接很多的情況下，數(shù)據(jù)庫本身可能已經(jīng)分庫分表，或者已經(jīng)通過業(yè)務(wù)繼續(xù)細(xì)分，將訪問分散了。所以過多的同一時間的訪問，這本身就是一個問題

2 對于數(shù)據(jù)庫的訪問，即使不使用PGbouncer 或者pgpool 程序本身也有連接池，對于連接的設(shè)計，在整體的程序設(shè)計之初就應(yīng)該有考慮，而不是最后讓數(shù)據(jù)庫承接這一切

3  對于任何的數(shù)據(jù)庫連接，都不是百分之百在同一時刻達(dá)到最大的處理數(shù)，及時是MYSQL 3000 MAX CONNECTIONS連接，在很細(xì)分的時間刻度上，同時訪問數(shù)據(jù)庫的基本也就是幾十個。PG 的連接狀態(tài)分為

1 active

2 idle

3 idle in transacton

4 aborted

這里PGbouncer 和PGPOOL 到底在幫助PG connections 做了什么

1 和 3,4 不是我們要關(guān)心的，而是idle 這個狀態(tài)，這也是大部分浪費連接數(shù)的關(guān)鍵位置，因為程序的連接池要維護(hù)一個連接數(shù)據(jù)庫的狀態(tài)，這也就導(dǎo)致有些時刻PG 大部分的連接的狀態(tài)在idle，所以要更高的利用 連接，讓數(shù)據(jù)庫使用有限的連接，接入更多的要工作的連接就是解決，少連接和應(yīng)用要多連接的矛盾，所謂的連接復(fù)用。。

2 另外如果你經(jīng)常發(fā)現(xiàn)你的連接狀態(tài)在 idle in transaction 這也就說明經(jīng)常有大事務(wù)長時間在等待什么，這也是解決問題的一個點，為什么一個事務(wù)要長時間霸占連接，并等待

另外還有一些連接，只連接不清理不關(guān)閉，可能是程序設(shè)計有失誤，這樣的情況我們可以設(shè)置對某個數(shù)據(jù)庫的連接的 statement_timeout ，在多長時間不工作我們就關(guān)掉這個連接。(設(shè)置60秒)

alter database 數(shù)據(jù)庫名 set statement_timeout = 60000;


這里最后總結(jié)一下

1 每個數(shù)據(jù)庫有自己的特性，這和數(shù)據(jù)庫設(shè)計的之初，架構(gòu)思路有關(guān)

2 數(shù)據(jù)庫的特性不是很好修改的，例如到目前MYSQL 也還是比較適合做OLTP，也沒有人讓他去做OLAP的操作一樣， 過度將一個數(shù)據(jù)庫神話，樣樣都行這不現(xiàn)實。

3  掌握某個數(shù)據(jù)庫的特點，并展開，讓本身的缺點弱化，這才是一個 DB 人員應(yīng)該做的。

關(guān)于PostgreSQL為什么接受大量連接到數(shù)據(jù)庫需要連接池就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。