2. 程式人生 > 其它 >pgbouncer連線池

pgbouncer連線池

阿新 • • 發佈：2021-06-10
目錄

背景

在做一站式專案的過程中發現當大量的服務連線到同一個庫，以及大量的開發人員連線到同一個庫的時候，資料庫的2000連線不夠。當然和使用c3p0連線池有關係，以前預設都是將最大最小連線數設定為一樣，但現在都是用druid連線池，所以最大和最小連線數不必設定為一樣。這樣可以減少連線數，當然這只是一方面，今天我們要說的是當有大量連線的時候pgbouncer連線池的使用

如果沒有資料庫連線池

資料庫在沒有任何連線池的情況下，應用程式必須直接訪問資料庫來建立連線。開啟的一個連線的消耗，關閉一個連線的消耗，而這樣的消耗，伴隨著你開啟的連線越多，則消耗的就越多。還有短連線，可能同時併發的連線多，但佔用這個連線的時間很短。這就會引起另一個問題，你設定的連線數和突入起來的連線數不匹配的情況，最後就會造成拒絕連線的問題。

所以這就對資料庫的連線提出一個問題，複用，連線的複用對資料庫非常重要，這可以降低某些快速連線，快速斷開的連線的資料庫訪問對資料庫效能的消耗和產生的一些不必要的麻煩。

版本

PgBouncer 1.11.x已經可以支援PostgreSQL 12

PgBouncer 1.14.0

也已經發布與PostgreSQL 13新功能匹配

pgbouncer的作用

既然應用已經使用了durid連線池了，那麼pgbouncer還有什麼用呢？

雖然我們每個服務都使用了連線池，但是各個服務之間是相互獨立的，當有許多的服務去連一個數據庫的時候，對資料庫來說這麼多連線還是不受保護的。（如果資料庫僅有少數的應用連線，那麼可以只使用程式自帶的連線池就夠了,但如果有大量的服務在連線資料庫，資料庫其實還是沒有收到連線池的保護）

另外，PG是多程序結構，每個程序大概耗費10MB左右記憶體，所以連線越多，耗費的記憶體也就越多。

使用軟體架構池對資料庫進行連線

使用durid連線池如下面所示，當有大量的應用連線資料庫的時候其實對資料庫來說這些連線還是沒有受到控制

使用pgbouncer連線池的方式對資料庫進行連線

pgbouncer是在資料庫端加了一個池子，也就是所有的連線經過資料庫都需要進入這個池子

採用pgbouncer來管理連線池的話，相當於在眾多的軟體druid連線池下面加了一個大的池子，來管理連線。這樣來保證資料庫的穩性。

當然，pg的連線池不僅僅pgbouncer、還有pgpool，pgbouncer功能更加精簡，配置簡單。

安裝配置：

安裝參考安裝文件

資料庫裡面對應的資料庫資訊需要在pgbouncer.ini配置裡面配置，listen_port是連線池對外的埠，應用配置時需要配置listen_port，如果直接配置資料庫的埠，那麼就沒有通過連線池

vi pgbouncer.ini

[databases]
pgbenchdb =  host=localhost port=6543 user=sa dbname=pgbenchdb  password=xxxx connect_query='SELECT 1' pool_size=100

[pgbouncer]       
logfile = /etc/pgbouncer/pgbouncer.log
pidfile = /etc/pgbouncer/pgbouncer.pid
auth_type = hba
auth_file = /etc/pgbouncer/userlist.txt
auth_hba_file =/etc/pgbouncer/pg_hba.conf
admin_users = sa
stats_users = sa
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 228
;min_pool_size = 0
reserve_pool_size = 10
listen_addr = 0.0.0.0    
listen_port = 5432  

--登入到pgbouncer，可以看到對應的版本為1.12.0
[thunisoft@sqlfx ~]$ psql -Usa -d pgbouncer -p 5432
psql (11.1, server 1.12.0/bouncer)
Type "help" for help.

--show help
pgbouncer=# show help;
NOTICE:  Console usage
DETAIL:  
	SHOW HELP|CONFIG|DATABASES|POOLS|CLIENTS|SERVERS|USERS|VERSION
	SHOW FDS|SOCKETS|ACTIVE_SOCKETS|LISTS|MEM
	SHOW DNS_HOSTS|DNS_ZONES
	SHOW STATS|STATS_TOTALS|STATS_AVERAGES|TOTALS
	SET key = arg
	RELOAD
	PAUSE [<db>]
	RESUME [<db>]
	DISABLE <db>
	ENABLE <db>
	RECONNECT [<db>]
	KILL <db>
	SUSPEND
	SHUTDOWN

SHOW

pgbouncer=# show databas;
ERROR:  invalid command 'show databas;', use SHOW HELP;
pgbouncer=# show databases;
   name    |     host      | port | database  | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections | paused | disabled 
-----------+---------------+------+-----------+------------+-----------+--------------+-----------+-----------------+---------------------+--------+----------
 pgbenchdb | xxxxxx | 6543 | pgbenchdb | sa         |       100 |           10 |           |               0 |                   0 |      0 |        0
 pgbouncer |               | 5432 | pgbouncer | pgbouncer  |         2 |            0 | statement |               0 |                   0 |      0 |        0
(2 rows)

效能測試

短連結

使用連線池：5985tps


[thunisoft@sqlfx ~]$ pgbench -M extended -v -r -P 1 -S -C -c 100 -j 100 -T 60 -p 5432 -Usa pgbenchdb
starting vacuum...end.
starting vacuum pgbench_accounts...end.
progress: 1.0 s, 6175.1 tps, lat 6.959 ms stddev 2.293
、、、
progress: 60.0 s, 6607.6 tps, lat 6.676 ms stddev 1.708
transaction type: <builtin: select only>
scaling factor: 100
query mode: extended
number of clients: 100
number of threads: 100
duration: 60 s
number of transactions actually processed: 359203
latency average = 7.426 ms
latency stddev = 5.283 ms
tps = 5985.437222 (including connections establishing)
tps = 13415.041978 (excluding connections establishing)
statement latencies in milliseconds:
         0.003  \set aid random(1, 100000 * :scale)
         7.425  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;

不使用連線池：752tps


[thunisoft@sqlfx ~]$ pgbench -M extended -v -r -P 1 -S -C -c 100 -j 100 -T 60 -p 6543 -Usa pgbenchdb
starting vacuum...end.
starting vacuum pgbench_accounts...end.
progress: 1.1 s, 656.3 tps, lat 8.981 ms stddev 7.668
、、、
progress: 60.0 s, 713.3 tps, lat 8.220 ms stddev 5.773
transaction type: <builtin: select only>
scaling factor: 100
query mode: extended
number of clients: 100
number of threads: 100
duration: 60 s
number of transactions actually processed: 45235
latency average = 7.972 ms
latency stddev = 6.182 ms
tps = 752.359996 (including connections establishing)
tps = 12079.524918 (excluding connections establishing)
statement latencies in milliseconds:
         0.005  \set aid random(1, 100000 * :scale)
         7.966  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;

短連結情況下使用連線池和不使用連線池，差別非常大。原因是建立大量的連線需要耗費大量的時間

高併發

使用連線池：565tps

--使用連線池，資料庫連線數為100
--這個地方的100是和pgbouncer.ini裡面的pool_size一致
pgbenchdb=# select count(*) from pg_stat_activity where state !='idle' and application_name = 'pgbench';
 count 
-------
   100
(1 row)


--初始化資料
 pgbench -i -s 20 pgbenchdb
dropping old tables...
creating tables...
generating data...
、、、
2000000 of 2000000 tuples (100%) done (elapsed 13.11 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.

--測試
[thunisoft@sqlfx ~]$ pgbench -M extended  -r -P 1   -c 1000 -j 1000 -T 60 -p 5432 -Usa pgbenchdb
starting vacuum...end.
、、、
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 20
query mode: extended
number of clients: 1000
number of threads: 1000
duration: 60 s
number of transactions actually processed: 34907
latency average = 1734.514 ms
latency stddev = 406.066 ms
tps = 565.477219 (including connections establishing)
tps = 565.611196 (excluding connections establishing)
statement latencies in milliseconds:
         0.006  \set aid random(1, 100000 * :scale)
         0.001  \set bid random(1, 1 * :scale)
         0.001  \set tid random(1, 10 * :scale)
         0.001  \set delta random(-5000, 5000)
      1471.673  BEGIN;
         2.593  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
         1.302  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
       105.564  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
       122.611  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
         2.311  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
        29.079  END;

不使用連線池：406tps

--不使用用連線池，資料庫連線數為1000
pgbenchdb=# select count(*) from pg_stat_activity where state !='idle' and application_name = 'pgbench';
 count 
-------
  1000
(1 row)

--初始化資料
[thunisoft@sqlfx ~]$  pgbench -i -s 20 pgbenchdb
dropping old tables...
creating tables...
generating data...
、、、
2000000 of 2000000 tuples (100%) done (elapsed 13.46 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.

--測試
[thunisoft@sqlfx ~]$  pgbench -M extended  -r -P 1   -c 1000 -j 1000 -T 60 -p 6543 -Usa pgbenchdb
starting vacuum...end.
progress: 2.5 s, 443.8 tps, lat 362.341 ms stddev 407.794
、、、
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 20
query mode: extended
number of clients: 1000
number of threads: 1000
duration: 60 s
number of transactions actually processed: 24946
latency average = 2375.957 ms
latency stddev = 3390.823 ms
tps = 406.784046 (including connections establishing)
tps = 409.912851 (excluding connections establishing)
statement latencies in milliseconds:
         0.016  \set aid random(1, 100000 * :scale)
         0.001  \set bid random(1, 1 * :scale)
         0.001  \set tid random(1, 10 * :scale)
         0.003  \set delta random(-5000, 5000)
         4.545  BEGIN;
         4.436  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
         2.508  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
      1950.669  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
       369.524  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
         3.705  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
        40.694  END;

可以看到使用pgbouncer連線池的tps要比不使用pgbouncer要稍高。使用了pgbouncer後，連線到資料庫的連線數為100，而不使用pgbouncer的連線數為1000

總結

1、在使用durid連線池的時候，最大最小連線池不必設定成一樣，這樣可以減小連線池開銷

2、durid連線池是應用端的池子，當連線資料庫的應用變多了以後，資料庫任然不受保護，並且連線越多耗費的記憶體越多

3、pgbouncer相當於在資料庫端加了一個池子，所有的連線過來都需要經過這個池子，負責連線的開啟和關閉

4、當有大量的服務連線到資料庫時，雖然有durid應用端連線池，但是對於資料庫來說，仍然像沒有使用連線池一樣，pgbouncer是資料庫端的連線池，用來控制應用端的連線

參考資料:

官網

pgbouncer使用

Scaling Connections in Postgres

PostgreSQL 與 Pgbouncer We are brotherhood

相關推薦

pgbouncer連線池

目錄背景版本pgbouncer的作用使用軟體架構池對資料庫進行連線使用pgbouncer連線池的方式對資料庫進行連線安裝配置：效能測試短連結使用連線池：5985tps不使用連線池：752tps高併發使用連線池：565tps不使用連線池：4

PgBouncer連線池工具

PgBouncer是為PostgreSQL提供的輕量級連線池工具，作用如下：1，能夠快取和PostgreSQL的連線，當有連線請求進來的時候，直接分配空閒程序，而不需要PostgreSQL fork出新程序來建立連線，以節省建立新程序，建立連線

golng mysql庫連線池分析

0x1 背景 golang的協程是好用，但是有時候瓶頸並不在語言上，而是在後面的資料來源上面，例如我們常見的mysql，redis等，當一個後端服務很多請求的時候，語言是能hold得住，但是

Spring Boot （三）： ORM 框架 JPA 與連線池 Hikari

前面兩篇文章我們介紹瞭如何快速建立一個 Spring Boot 工程《Spring Boot（一）：快速開始》和在 Spring Boot 中如何使用模版引擎 Thymeleaf 渲染一個Web頁面《Spring Boot （二）：模版引擎 Thymeleaf 渲染 Web 頁

Spring Boot （四）： Druid 連線池密碼加密與監控

在上一篇文章《Spring Boot （三）： ORM 框架 JPA 與連線池 Hikari》 我們介紹了 JPA 與連線池 Hikari 的整合使用，在國內使用比較多的連線池還有一個是阿里開源的 Druid 。本篇文章我們就來聊一聊 Druid 的一些

【重溫mysql】1、連線池

在我們日常的開發中，會經常與資料庫打交道。對於 java 開發者來說，經常會使用jdbc來與資料庫進行互動。我們可能會看到這樣的程式碼：

Spring Boot Mysql 版本驅動連線池方案選擇

國內環境下，用Mysql還是比較多的。這裡簡單的總結了一下，如有繆誤，還請指正。

springboot2.0使用Hikari連線池的方法（替換druid）

1.springboot 2.0 預設連線池就是Hikari了，所以引用parents後不用專門加依賴 2.貼我自己的配置（時間單位都是毫秒）

如何解決執行緒太多導致java socket連線池出現的問題

這篇文章主要介紹瞭如何解決執行緒太多導致socket連線池出現的問題,文中通過示例程式碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下

關於資料庫連線池Druid使用說明

根據綜合性能，可靠性，穩定性，擴充套件性，易用性等因素替換成最優的資料庫連線池。

用sqlalchemy構建Django連線池的例項

都知道django每次請求都會連線資料庫和釋放資料庫連線。Django為每個請求使用新的資料庫連線。一開始這個方法行得通。然而隨著伺服器上的負載的增加,建立/銷燬連線資料庫開始花大量的時間。要避免這個，你可以使用資

淺談django url請求與資料庫連線池的共享問題

但凡介紹資料庫連線池的文章，都會說“資料庫連線是一種關鍵的有限的昂貴的資源，這一點在多使用者的網頁應用程式中體現得尤為突出。對資料庫連線的管理能顯著影響到整個應用程式的伸縮性和健壯性，影響到程式的效能

workerman寫mysql連線池的例項程式碼

首先要了解為什麼用連線池，連線池能為你解決什麼問題 連線池主要的作用：

SQL學習基礎——MySQL入門（4）_JDBC資料庫連線池

文章目錄1. 資料庫連線池1. 概念：2. 好處：3. 實現：4. C3P0：資料庫連線池技術5. Druid：資料庫連線池實現技術，由阿里巴巴提供的2.Spring JDBC

【SpringBoot 2學習筆記】《九》SpringBoot2資料庫訪問之Druid連線池

為什麼要使用資料庫連線池 不使用資料庫連線池： 對於併發量大的網站，會導致以下問題：

JDBC自定義連線池過程詳解

這篇文章主要介紹了JDBC自定義連線池過程詳解,文中通過示例程式碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下

 Druid：資料庫連線池實現技術

 Druid：資料庫連線池實現技術，由阿里巴巴提供的     1. 步驟：         1. 匯入jar包 druid-1.0.9.jar

Golang連線池的幾種實現案例小結

因為TCP的三隻握手等等原因，建立一個連線是一件成本比較高的行為。所以在一個需要多次與特定實體互動的程式中，就需要維持一個連線池，裡面有可以複用的連線可供重複使用。

Java使用MySQL實現連線池程式碼例項

官方：資料庫連線池（Connection pooling）是程式啟動時建立足夠的資料庫連線，並將這些連線組成一個連線池，由程式動態地對連線池中的連線進行申請，使用，釋放。

構建高效的python requests長連線池詳解

前文： 最近在搞全網的CDN刷新系統，在效能調優時遇到了requests長連線的一個問題，以前關注過長連線太多造成浪費的問題，但因為系統都是分散式擴充套件的，針對這種各別問題就懶得改動了。 現在開發的快取刷新系統，