引言

在 PostgreSQL 的生產(chǎn)運(yùn)維中，“連接數(shù)過(guò)多”是最常見(jiàn)且影響深遠(yuǎn)的性能問(wèn)題之一。當(dāng)數(shù)據(jù)庫(kù)連接數(shù)接近或達(dá)到 max_connections 限制時(shí)，新連接請(qǐng)求將被拒絕，導(dǎo)致應(yīng)用報(bào)錯(cuò)“too many connections”，服務(wù)不可用。即使未達(dá)上限，大量空閑連接也會(huì)消耗內(nèi)存、文件描述符和 CPU 資源，降低整體吞吐能力。

本文將系統(tǒng)性地剖析 連接數(shù)過(guò)多的根本原因，詳解 PostgreSQL 連接機(jī)制與資源開(kāi)銷(xiāo)，并對(duì)比主流 連接池方案（pgBouncer、PgPool-II、應(yīng)用層池） 的原理、配置與適用場(chǎng)景，提供一套從診斷到治理的完整解決方案。

一、PostgreSQL 連接機(jī)制與資源模型

1. 進(jìn)程模型

PostgreSQL 采用 “進(jìn)程每連接”（Process-Per-Connection） 模型：

• 每個(gè)客戶(hù)端連接對(duì)應(yīng)一個(gè)獨(dú)立的后端進(jìn)程（backend process）；
• 該進(jìn)程負(fù)責(zé)處理該連接的所有 SQL 請(qǐng)求，直至斷開(kāi)。

對(duì)比：MySQL 默認(rèn)使用線程模型（可配置為線程池），而 PostgreSQL 堅(jiān)持進(jìn)程模型以保障穩(wěn)定性與隔離性。

2. 連接資源開(kāi)銷(xiāo)

每個(gè)連接消耗的資源包括：

假設(shè) max_connections = 1000，僅連接本身即可消耗 5–10 GB 內(nèi)存，還不包括查詢(xún)執(zhí)行時(shí)的額外內(nèi)存（如排序、哈希）。

3. 關(guān)鍵參數(shù)：max_connections

• 定義數(shù)據(jù)庫(kù)允許的最大并發(fā)連接數(shù)；
• 默認(rèn)值通常為 100；
• 修改需重啟 PostgreSQL；
• 實(shí)際可用連接數(shù) = max_connections - superuser_reserved_connections（默認(rèn)保留 3 個(gè)給超級(jí)用戶(hù)）。

盲目調(diào)高 max_connections 是反模式——它掩蓋問(wèn)題而非解決問(wèn)題，且極易引發(fā) OOM（Out-Of-Memory）。

二、連接數(shù)過(guò)多的根本原因分析

1. 應(yīng)用層連接泄漏（最常見(jiàn)）

• 應(yīng)用代碼未正確關(guān)閉數(shù)據(jù)庫(kù)連接；
• 連接池配置不當(dāng)（如未設(shè)置最大連接數(shù)、未啟用超時(shí)回收）；
• 異常路徑未釋放連接（try-finally 缺失）。

典型表現(xiàn)：

• 連接數(shù)隨時(shí)間持續(xù)增長(zhǎng)，不隨業(yè)務(wù)低峰下降；
• pg_stat_activity 中大量 idle 狀態(tài)連接。

2. 高并發(fā)短連接風(fēng)暴

• 應(yīng)用未使用連接池，每次請(qǐng)求新建連接；
• HTTP 服務(wù)每秒處理數(shù)千請(qǐng)求，每個(gè)請(qǐng)求建連+查+斷開(kāi)；
• 導(dǎo)致連接頻繁創(chuàng)建/銷(xiāo)毀，系統(tǒng)負(fù)載飆升。

典型表現(xiàn)：

• 連接數(shù)劇烈波動(dòng)；
• pg_stat_activity 中大量 active → idle 快速切換；
• 系統(tǒng) CPU 消耗在進(jìn)程 fork/exit 上。

3. 長(zhǎng)事務(wù)或長(zhǎng)查詢(xún)阻塞

• 某些連接執(zhí)行長(zhǎng)時(shí)間運(yùn)行的查詢(xún)或事務(wù)；
• 連接被占用無(wú)法釋放；
• 新請(qǐng)求不斷堆積，連接數(shù)激增。

典型表現(xiàn)：

• pg_stat_activity 中存在 state = 'active' 且 query_start 很早的記錄；
• wait_event 顯示鎖等待或 I/O 等待。

4. 連接池配置不合理

• 連接池的最大連接數(shù) > PostgreSQL 的 max_connections；
• 多個(gè)應(yīng)用實(shí)例各自維護(hù)連接池，總和遠(yuǎn)超數(shù)據(jù)庫(kù)承載能力。

典型表現(xiàn)：

• 多個(gè)應(yīng)用同時(shí)報(bào) “too many connections”；
• 數(shù)據(jù)庫(kù)連接數(shù)穩(wěn)定在 max_connections 附近。

三、診斷：如何確認(rèn)連接數(shù)問(wèn)題？

1. 查看當(dāng)前連接數(shù)

-- 總連接數(shù)（含后臺(tái)進(jìn)程）
SELECT count(*) FROM pg_stat_activity;

-- 用戶(hù)連接數(shù)（排除 autovacuum 等）
SELECT count(*) 
FROM pg_stat_activity 
WHERE backend_type = 'client backend';

-- 按狀態(tài)分類(lèi)
SELECT state, count(*) 
FROM pg_stat_activity 
WHERE backend_type = 'client backend'
GROUP BY state;

常見(jiàn)狀態(tài)：

• active：正在執(zhí)行查詢(xún)；
• idle：已執(zhí)行完，等待新查詢(xún)；
• idle in transaction：在事務(wù)中但無(wú)活動(dòng)（危險(xiǎn)！可能長(zhǎng)事務(wù)）；
• idle in transaction (aborted)：事務(wù)出錯(cuò)但未結(jié)束。

2. 識(shí)別異常連接

（1）長(zhǎng)時(shí)間空閑連接

SELECT pid, usename, application_name, client_addr, 
       now() - state_change AS idle_duration, query
FROM pg_stat_activity
WHERE state = 'idle'
  AND backend_type = 'client backend'
  AND now() - state_change > INTERVAL '30 minutes'
ORDER BY idle_duration DESC;

（2）長(zhǎng)事務(wù)

SELECT pid, usename, xact_start, 
       now() - xact_start AS xact_duration, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
  AND backend_type = 'client backend'
  AND now() - xact_start > INTERVAL '5 minutes'
ORDER BY xact_duration DESC;

3. 監(jiān)控連接趨勢(shì)

• 使用 Prometheus + postgres_exporter 采集 pg_stat_activity 指標(biāo)；
• Grafana 面板展示連接數(shù)隨時(shí)間變化；
• 設(shè)置告警：pg_stat_activity_count > 0.8 * max_connections。

四、解決方案：連接池的核心價(jià)值

連接池通過(guò) “連接復(fù)用” 解決上述問(wèn)題：

• 應(yīng)用向連接池請(qǐng)求連接，而非直接連數(shù)據(jù)庫(kù)；
• 連接池維護(hù)一個(gè)固定大小的“后端連接池”；
• 應(yīng)用使用完后歸還連接，供其他請(qǐng)求復(fù)用；
• 有效解耦 應(yīng)用并發(fā)數(shù) 與 數(shù)據(jù)庫(kù)連接數(shù)。

例如：1000 個(gè)應(yīng)用并發(fā)請(qǐng)求，可通過(guò) 50 個(gè)數(shù)據(jù)庫(kù)連接處理。

五、主流連接池方案對(duì)比

推薦組合：

• 微服務(wù)架構(gòu)：應(yīng)用層池（如 HikariCP） + pgBouncer
• 單體/傳統(tǒng)架構(gòu)：pgBouncer

六、pgBouncer 詳解（最廣泛使用的連接池）

1. 工作模式

• Session 模式：連接綁定到客戶(hù)端會(huì)話(huà)，直到斷開(kāi)；
• Transaction 模式（推薦）：每個(gè)事務(wù)結(jié)束后立即歸還連接；
• Statement 模式：每條語(yǔ)句后歸還（不支持多語(yǔ)句事務(wù)）。

Transaction 模式可最大化連接復(fù)用率，適用于無(wú)狀態(tài)應(yīng)用。

2. 安裝與配置

（1）安裝（以 Ubuntu 為例）

sudo apt-get install pgbouncer

（2）核心配置文件/etc/pgbouncer/pgbouncer.ini

[databases]
mydb = host=localhost port=5432 dbname=prod

[pgbouncer]
listen_port = 6432
listen_addr = *
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/log/pgbouncer/pgbouncer.pid

; 連接池大?。P(guān)鍵?。?
default_pool_size = 50        ; 每個(gè)用戶(hù)-數(shù)據(jù)庫(kù)對(duì)的最大后端連接數(shù)
max_db_connections = 100      ; 單個(gè)數(shù)據(jù)庫(kù)的最大總連接數(shù)
max_user_connections = 100    ; 單個(gè)用戶(hù)的最大總連接數(shù)

; 超時(shí)設(shè)置
server_idle_timeout = 600     ; 后端連接空閑 10 分鐘后關(guān)閉
server_lifetime = 3600        ; 后端連接存活 1 小時(shí)后重建

（3）用戶(hù)認(rèn)證文件/etc/pgbouncer/userlist.txt

"app_user" "md5加密密碼"

密碼可通過(guò) pg_md5 工具生成。

3. 應(yīng)用連接方式

應(yīng)用不再連接 5432，而是連接 6432：

# Python 示例
conn = psycopg2.connect(
    host='localhost',
    port=6432,
    database='mydb',
    user='app_user',
    password='xxx'
)

4. 監(jiān)控與管理

連接 pgBouncer 的虛擬數(shù)據(jù)庫(kù) pgbouncer：

-- 查看連接池狀態(tài)
SHOW POOLS;
-- 輸出：database, user, cl_active, cl_waiting, sv_active, sv_idle...

-- 查看客戶(hù)端連接
SHOW CLIENTS;

-- 查看后端連接
SHOW SERVERS;

關(guān)鍵指標(biāo)：

• cl_waiting：等待連接的客戶(hù)端數(shù)（>0 表示池不足）；
• sv_idle：空閑的后端連接數(shù)。

七、應(yīng)用層連接池配置建議（以 HikariCP 為例）

若使用 Java + Spring Boot，HikariCP 是首選。

1. 核心配置

spring:
  datasource:
    hikari:
      maximum-pool-size: 20          # 應(yīng)用實(shí)例的最大連接數(shù)
      minimum-idle: 5                # 最小空閑連接
      idle-timeout: 600000           # 10 分鐘空閑超時(shí)
      max-lifetime: 1800000          # 連接最大存活 30 分鐘
      connection-timeout: 3000       # 獲取連接超時(shí) 3 秒

2. 多實(shí)例部署下的總連接數(shù)控制

假設(shè)有 N 個(gè)應(yīng)用實(shí)例，每個(gè)配置 maximum-pool-size = M，則總連接數(shù) ≈ N × M。

必須滿(mǎn)足：

N × M ≤ pgBouncer.max_db_connections ≤ PostgreSQL.max_connections

示例：10 個(gè)實(shí)例 × 20 連接 = 200，需確保數(shù)據(jù)庫(kù) max_connections ≥ 210（含預(yù)留）。

八、高級(jí)優(yōu)化與陷阱規(guī)避

1. 避免“連接池嵌套”

• 應(yīng)用層池 + pgBouncer 是合理的；
• 但不要在 pgBouncer 后再接另一個(gè)連接池（如 PgPool-II），會(huì)導(dǎo)致復(fù)雜性和性能損耗。

2. 正確處理事務(wù)

• 在 pgBouncer 的 Transaction 模式下，禁止跨事務(wù)的會(huì)話(huà)級(jí)設(shè)置：

-- 錯(cuò)誤：SET 會(huì)在事務(wù)結(jié)束后丟失
BEGIN;
SET LOCAL timezone = 'UTC';
SELECT ...;
COMMIT; -- 此時(shí) SET 生效，但下次事務(wù)無(wú)效

-- 更危險(xiǎn)：跨多個(gè) BEGIN/COMMIT
SET timezone = 'UTC'; -- 在 Transaction 模式下無(wú)效！
BEGIN; SELECT ...; COMMIT;
BEGIN; SELECT ...; COMMIT; -- timezone 不是 UTC

解決方案：使用 application_name 傳遞上下文，或改用 Session 模式（犧牲復(fù)用率）。

3. 監(jiān)控連接池健康度

• 應(yīng)用層：監(jiān)控 HikariPool-connection-acquired-nanoseconds 等指標(biāo)；
• pgBouncer：監(jiān)控 cl_waiting，若持續(xù) >0，需擴(kuò)容池大??；
• 數(shù)據(jù)庫(kù)：確保 pg_stat_activity 中后端連接數(shù)穩(wěn)定。

4. 自動(dòng)擴(kuò)縮容（Kubernetes 場(chǎng)景）

• 使用 Horizontal Pod Autoscaler (HPA) 基于 cl_waiting 指標(biāo)擴(kuò)縮 pgBouncer；
• 或基于應(yīng)用的連接等待時(shí)間動(dòng)態(tài)調(diào)整 maximum-pool-size。

九、連接數(shù)治理 SOP（標(biāo)準(zhǔn)操作流程）

監(jiān)控告警：

• 設(shè)置連接數(shù)閾值告警（>80% max_connections）；
• 監(jiān)控 idle in transaction 連接。

根因分析：

• 區(qū)分是連接泄漏、短連接風(fēng)暴還是長(zhǎng)事務(wù)；
• 使用 pg_stat_activity 定位源頭。

短期緩解：

• 終止異常連接：SELECT pg_terminate_backend(pid);
• 臨時(shí)增加 max_connections（僅應(yīng)急）。

長(zhǎng)期治理：

• 引入 pgBouncer 或應(yīng)用層連接池；
• 修復(fù)代碼中的連接泄漏；
• 優(yōu)化長(zhǎng)事務(wù)。

容量規(guī)劃：

• 基于業(yè)務(wù)峰值 QPS 和平均查詢(xún)耗時(shí)，計(jì)算所需連接數(shù)：

所需連接數(shù) ≈ (QPS × 平均查詢(xún)時(shí)間) / 并發(fā)系數(shù)

• 預(yù)留 20% 余量。

結(jié)語(yǔ)：連接數(shù)過(guò)多本質(zhì)是 “資源錯(cuò)配” ——應(yīng)用并發(fā)需求與數(shù)據(jù)庫(kù)連接能力不匹配。解決之道不在盲目擴(kuò)容，而在 引入連接池、規(guī)范應(yīng)用行為、精細(xì)化監(jiān)控。

pgBouncer 作為輕量、高效、穩(wěn)定的連接池中間件，已成為 PostgreSQL 生態(tài)的事實(shí)標(biāo)準(zhǔn)。結(jié)合應(yīng)用層連接池，可構(gòu)建彈性、可擴(kuò)展的數(shù)據(jù)庫(kù)訪問(wèn)架構(gòu)。

記?。?strong>一個(gè)設(shè)計(jì)良好的連接池，勝過(guò)十倍的硬件升級(jí)。

以上就是PostgreSQL連接數(shù)過(guò)多的原因分析與連接池方案的詳細(xì)內(nèi)容，更多關(guān)于PostgreSQL連接數(shù)過(guò)多的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！