PostgreSQL 是一個(gè)功能強(qiáng)大、穩(wěn)定可靠的開(kāi)源關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)，廣泛應(yīng)用于各種規(guī)模的企業(yè)和項(xiàng)目中。然而，在實(shí)際使用過(guò)程中，用戶(hù)偶爾會(huì)遇到“數(shù)據(jù)庫(kù)卡頓”——即查詢(xún)響應(yīng)變慢、連接堆積、甚至整個(gè)實(shí)例暫時(shí)無(wú)響應(yīng)的現(xiàn)象。這類(lèi)問(wèn)題往往不是單一原因造成的，而是多種因素交織作用的結(jié)果。

本文將從 PostgreSQL 的核心原理出發(fā)，深入剖析導(dǎo)致“偶爾卡頓”的常見(jiàn)原因，并結(jié)合底層機(jī)制進(jìn)行解釋?zhuān)瑤椭?DBA 和開(kāi)發(fā)者理解問(wèn)題本質(zhì)，從而更有效地排查與優(yōu)化。

一、PostgreSQL 架構(gòu)簡(jiǎn)述

1.1 關(guān)鍵架構(gòu)組件

在深入問(wèn)題之前，先快速回顧 PostgreSQL 的關(guān)鍵架構(gòu)組件：

• 后端進(jìn)程模型：每個(gè)客戶(hù)端連接對(duì)應(yīng)一個(gè)獨(dú)立的后端進(jìn)程（backend process），通過(guò)共享內(nèi)存通信。
• 共享緩沖區(qū)（Shared Buffers）：用于緩存數(shù)據(jù)頁(yè)，減少磁盤(pán) I/O。
• WAL（Write-Ahead Logging）機(jī)制：所有修改先寫(xiě)入 WAL 日志，再應(yīng)用到數(shù)據(jù)文件，保障 ACID。
• MVCC（多版本并發(fā)控制）：通過(guò)版本鏈實(shí)現(xiàn)讀寫(xiě)不阻塞，但會(huì)產(chǎn)生“死元組”（dead tuples）。
• VACUUM 機(jī)制：清理死元組、更新統(tǒng)計(jì)信息、防止事務(wù) ID 回卷（wraparound）。
• 檢查點(diǎn)（Checkpoint）：將臟頁(yè)從共享緩沖區(qū)刷入磁盤(pán)，確保崩潰恢復(fù)效率。
• 鎖與等待機(jī)制：包括表級(jí)鎖、行級(jí)鎖、輕量級(jí)鎖（LWLock）等。

這些機(jī)制共同保障了 PostgreSQL 的一致性、可靠性和并發(fā)能力，但也可能在特定條件下成為性能瓶頸。

1.2 卡頓核心原因總結(jié)

PostgreSQL 的“偶爾卡頓”通常不是 bug，而是其穩(wěn)健架構(gòu)在高負(fù)載或配置不當(dāng)下的自然表現(xiàn)。核心原因可歸結(jié)為：

預(yù)防勝于治療：合理的配置、完善的監(jiān)控、定期維護(hù)（VACUUM/ANALYZE）、良好的應(yīng)用設(shè)計(jì)（短事務(wù)、連接池），是避免“卡頓”的關(guān)鍵。

二、“偶爾卡頓”的典型場(chǎng)景與核心原因

2.1 檢查點(diǎn)（Checkpoint）風(fēng)暴

現(xiàn)象：每隔一段時(shí)間（如 checkpoint_timeout 設(shè)置為 5 分鐘），數(shù)據(jù)庫(kù)突然變慢幾秒到幾十秒，I/O 利用率飆升。

原理：PostgreSQL 在檢查點(diǎn)期間會(huì)將共享緩沖區(qū)中的“臟頁(yè)”（被修改但未寫(xiě)入磁盤(pán)的數(shù)據(jù)頁(yè)）批量刷入磁盤(pán)。如果在兩次檢查點(diǎn)之間積累了大量臟頁(yè)（例如高寫(xiě)入負(fù)載），檢查點(diǎn)過(guò)程會(huì)觸發(fā)大量同步 I/O，導(dǎo)致 I/O 隊(duì)列擁堵，進(jìn)而影響其他查詢(xún)。

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

• checkpoint_timeout：檢查點(diǎn)間隔（默認(rèn) 5min）
• max_wal_size：WAL 文件最大值，間接控制臟頁(yè)積累量
• checkpoint_completion_target：檢查點(diǎn)平滑完成目標(biāo)比例（建議設(shè)為 0.9）

優(yōu)化建議：增大 max_wal_size（如 4GB~8GB），調(diào)高 checkpoint_completion_target（0.9），讓檢查點(diǎn)更平滑；同時(shí)確保磁盤(pán) I/O 能力足夠（如使用 SSD）。

2.2 AUTOVACUUM 滯后或爆發(fā)式運(yùn)行

現(xiàn)象：某張大表長(zhǎng)時(shí)間未被清理，突然觸發(fā)一次大規(guī)模 VACUUM，CPU 或 I/O 突增，查詢(xún)變慢。

原理：PostgreSQL 使用 MVCC，UPDATE/DELETE 不會(huì)立即刪除舊數(shù)據(jù)，而是標(biāo)記為“死元組”。若不及時(shí)清理，會(huì)導(dǎo)致：

• 表膨脹（bloat）：物理大小遠(yuǎn)大于邏輯數(shù)據(jù)量
• 查詢(xún)需掃描更多無(wú)效數(shù)據(jù)
• 索引效率下降

autovacuum 進(jìn)程會(huì)自動(dòng)清理，但若配置不當(dāng)（如 autovacuum_vacuum_scale_factor 過(guò)大）或系統(tǒng)負(fù)載過(guò)高，可能導(dǎo)致清理滯后，最終積壓成“雪崩式”VACUUM。

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

• autovacuum_vacuum_scale_factor（默認(rèn) 0.2）+ autovacuum_vacuum_threshold（默認(rèn) 50）
• autovacuum_max_workers：最大并發(fā) autovacuum 進(jìn)程數(shù)
• maintenance_work_mem：影響 VACUUM 效率

優(yōu)化建議：

• 對(duì)高頻更新表，設(shè)置更激進(jìn)的 autovacuum 策略（如 scale_factor=0.05）
• 監(jiān)控 pg_stat_user_tables.n_dead_tup，及時(shí)發(fā)現(xiàn)膨脹
• 使用 pg_repack 或 VACUUM FULL（謹(jǐn)慎！會(huì)鎖表）處理嚴(yán)重膨脹

2.3 事務(wù) ID 回卷（Transaction ID Wraparound）風(fēng)險(xiǎn)

現(xiàn)象：數(shù)據(jù)庫(kù)突然進(jìn)入只讀模式，或出現(xiàn)“database is not accepting commands to avoid wraparound data loss”錯(cuò)誤。

原理：PostgreSQL 使用 32 位事務(wù) ID（XID），最多支持約 20 億個(gè)事務(wù)。為防止回卷導(dǎo)致數(shù)據(jù)丟失，系統(tǒng)要求所有活躍事務(wù)的 XID 必須在“安全窗口”內(nèi)。若未及時(shí)執(zhí)行 VACUUM 更新 relfrozenxid，系統(tǒng)會(huì)強(qiáng)制凍結(jié)（freeze）舊元組。

當(dāng)接近回卷閾值（約 15 億事務(wù)）時(shí)，PostgreSQL 會(huì)啟動(dòng)緊急 autovacuum，甚至阻止新寫(xiě)入。

注意：這不是“偶爾卡頓”，而是嚴(yán)重故障前兆！

優(yōu)化建議：

• 定期監(jiān)控 age(datfrozenxid)，確保 < 10 億
• 對(duì)大表啟用 autovacuum_freeze_max_age 調(diào)優(yōu)（默認(rèn) 2 億，可適當(dāng)降低）
• 避免長(zhǎng)事務(wù)（如未提交的 idle in transaction）

2.4 長(zhǎng)事務(wù)或空閑事務(wù)（idle in transaction）

現(xiàn)象：某些查詢(xún)長(zhǎng)時(shí)間不返回，其他會(huì)話(huà)無(wú)法 UPDATE/DELETE 某些行。

原理：PostgreSQL 的 MVCC 依賴(lài)于“最老活躍事務(wù)”來(lái)判斷哪些元組仍需保留。若存在一個(gè)長(zhǎng)時(shí)間未提交的事務(wù)（即使是 BEGIN; SELECT ...; 后掛起），會(huì)導(dǎo)致：

• 死元組無(wú)法被 VACUUM 清理
• 表持續(xù)膨脹
• 鎖等待（如行鎖、謂詞鎖）

即使該事務(wù)不做任何修改，也會(huì)阻礙系統(tǒng)清理。

排查命令：

SELECT pid, query, state, now() - xact_start AS xact_age
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY xact_age DESC;

優(yōu)化建議：

• 應(yīng)用層避免開(kāi)啟事務(wù)后長(zhǎng)時(shí)間不提交
• 設(shè)置 idle_in_transaction_session_timeout（如 5min）自動(dòng)終止空閑事務(wù)

2.5 鎖競(jìng)爭(zhēng)與死鎖

現(xiàn)象：部分查詢(xún)長(zhǎng)時(shí)間等待，pg_stat_activity.wait_event 顯示 Lock 或 relation 等待。

原理：雖然 PostgreSQL 讀寫(xiě)不阻塞，但在以下情況仍會(huì)加鎖：

• DDL 操作（如 ALTER TABLE）需要排他鎖
• SELECT FOR UPDATE 顯式加行鎖
• 大量并發(fā) UPDATE 同一行

若鎖持有時(shí)間過(guò)長(zhǎng)，或鎖順序不一致，會(huì)導(dǎo)致連鎖等待甚至死鎖。

排查工具：

-- 查看鎖等待
SELECT blocked_locks.pid     AS blocked_pid,
       blocking_locks.pid    AS blocking_pid,
       blocked_activity.query AS blocked_query,
       blocking_activity.query AS blocking_query
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
    ON blocking_locks.locktype = blocked_locks.locktype
    AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
    AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
    AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
    AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
    AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
    AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
    AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
    AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
    AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
    AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;

優(yōu)化建議：

• 減少事務(wù)粒度，盡快提交
• 避免在事務(wù)中執(zhí)行耗時(shí)操作（如網(wǎng)絡(luò)調(diào)用）
• 統(tǒng)一訪問(wèn)順序，避免死鎖

2.6 WAL 寫(xiě)入瓶頸與 WAL 歸檔延遲

現(xiàn)象：高寫(xiě)入負(fù)載下，wal writer 或 checkpointer 進(jìn)程 CPU/I/O 高，主庫(kù)延遲上升。

原理：所有修改必須先寫(xiě)入 WAL（順序?qū)懀?，再異步刷盤(pán)。若：

• 磁盤(pán)寫(xiě)入速度慢（尤其是 HDD）
• WAL 歸檔（archive_command）執(zhí)行慢
• 流復(fù)制備庫(kù)延遲嚴(yán)重

會(huì)導(dǎo)致 WAL 文件堆積，甚至觸發(fā) max_wal_size 限制，迫使檢查點(diǎn)提前，加劇 I/O 壓力。

優(yōu)化建議：

• 使用高速磁盤(pán)（NVMe SSD）存放 WAL（pg_wal 目錄）
• 優(yōu)化 archive_command（如使用 WAL-G、并行歸檔）
• 監(jiān)控 pg_stat_archiver 和 pg_stat_wal_receiver

2.7 共享內(nèi)存爭(zhēng)用（LWLock 等待）

現(xiàn)象：高并發(fā)下，wait_event 顯示 WALWriteLock、BufferContent、ProcArrayLock 等輕量級(jí)鎖等待。

原理：PostgreSQL 使用輕量級(jí)鎖（LWLock）保護(hù)共享結(jié)構(gòu)（如緩沖區(qū)、WAL 緩沖區(qū)、進(jìn)程數(shù)組）。在極高并發(fā)（數(shù)千連接）下，這些鎖可能成為瓶頸。

典型案例：

• 大量短連接頻繁創(chuàng)建/銷(xiāo)毀 → ProcArrayLock 爭(zhēng)用
• 高頻小事務(wù) → WALWriteLock 爭(zhēng)用

優(yōu)化建議：

• 使用連接池（如 PgBouncer）減少后端進(jìn)程數(shù)
• 調(diào)整 wal_buffers（默認(rèn) -1，通常足夠）
• 升級(jí)到 PostgreSQL 14+（引入 WAL 并發(fā)寫(xiě)入優(yōu)化）

2.8 查詢(xún)計(jì)劃突變（Plan Regression）

現(xiàn)象：某個(gè)原本很快的查詢(xún)突然變慢，且每次執(zhí)行都慢（非“偶爾”），但有時(shí)因統(tǒng)計(jì)信息更新又恢復(fù)正常。

原理：PostgreSQL 依賴(lài)統(tǒng)計(jì)信息（pg_stats）生成執(zhí)行計(jì)劃。若：

• 表數(shù)據(jù)分布突變（如新增大量數(shù)據(jù)）
• ANALYZE 未及時(shí)執(zhí)行
• 參數(shù)化查詢(xún)因綁定變量值不同選擇不同計(jì)劃

可能導(dǎo)致優(yōu)化器選擇低效計(jì)劃（如嵌套循環(huán)代替哈希連接）。

優(yōu)化建議：

• 定期 ANALYZE，或啟用 track_counts = on
• 對(duì)關(guān)鍵查詢(xún)使用 PREPARE 或 plan caching
• 使用 pg_hint_plan 強(qiáng)制計(jì)劃（臨時(shí)手段）
• 升級(jí)到 PostgreSQL 16+（支持 plan invalidation 自動(dòng)刷新）

三、如何系統(tǒng)性排查“偶爾卡頓”？（重要）

• 監(jiān)控基礎(chǔ)指標(biāo)：
  • CPU、內(nèi)存、I/O（iostat, iotop）
  • PostgreSQL：pg_stat_statements（慢查詢(xún)）、pg_stat_activity（活躍會(huì)話(huà)）、pg_stat_bgwriter（緩沖區(qū)寫(xiě)入）
• 抓取卡頓時(shí)的快照：

-- 活躍會(huì)話(huà)與等待事件
SELECT pid, wait_event_type, wait_event, query, state FROM pg_stat_activity WHERE state <> 'idle';

-- 鎖等待
SELECT * FROM pg_locks WHERE granted = false;

-- 檢查點(diǎn)與 bgwriter 統(tǒng)計(jì)
SELECT * FROM pg_stat_bgwriter;

• 啟用日志診斷：
  • log_min_duration_statement = 1000（記錄慢查詢(xún)）
  • log_checkpoints = on
  • log_autovacuum_min_duration = 0（記錄所有 autovacuum）
• 使用專(zhuān)業(yè)工具：
  • pgBadger：日志分析
  • pg_top / htop：實(shí)時(shí)進(jìn)程監(jiān)控
  • perf / flamegraph：CPU 火焰圖（需編譯帶符號(hào)的 PostgreSQL）

到此這篇關(guān)于PostgreSQL核心原理之?dāng)?shù)據(jù)庫(kù)偶爾會(huì)卡頓的原因分析的文章就介紹到這了,更多相關(guān)postgresql數(shù)據(jù)庫(kù)卡頓內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！