PostgreSQL為什么接受大量連接到數據庫需要連接池

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

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

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

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

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

實際上我并沒有如愿, PG 還是穩穩的運行, 但系統有一點緩慢,有點卡的感覺

內存方面

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

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

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

其中上面的each backend has a PGPROC struct in shared memory , + 后面的那句, 應該表明 backend  和  shared memory 之間 存在一個pgproc的結構, 這個結構的主要作用就是 復用.

后面的NOTE 的twophase.c 證明了PGPROC 結構的復用,因為當前的transaction 在隊列中 有兩個狀態, 真正運行和準備運行.

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

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

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

內存的使用也未占滿.

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

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

內存的使用也未占滿.

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

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

1 為什么要有并發有那么多的連接， 例如一個數據庫要承受3000+以上的連接數，即使是互聯網屬性，整體的架構設計是什么，如果并發的連接很多的情況下，數據庫本身可能已經分庫分表，或者已經通過業務繼續細分，將訪問分散了。所以過多的同一時間的訪問，這本身就是一個問題

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

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

1 active

2 idle

3 idle in transacton

4 aborted

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

1 和 3,4 不是我們要關心的，而是idle 這個狀態，這也是大部分浪費連接數的關鍵位置，因為程序的連接池要維護一個連接數據庫的狀態，這也就導致有些時刻PG 大部分的連接的狀態在idle，所以要更高的利用 連接，讓數據庫使用有限的連接，接入更多的要工作的連接就是解決，少連接和應用要多連接的矛盾，所謂的連接復用。。

2 另外如果你經常發現你的連接狀態在 idle in transaction 這也就說明經常有大事務長時間在等待什么，這也是解決問題的一個點，為什么一個事務要長時間霸占連接，并等待

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

alter database 數據庫名 set statement_timeout = 60000;


這里最后總結一下

1 每個數據庫有自己的特性，這和數據庫設計的之初，架構思路有關

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

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

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