HDUO Lab

深入 PostgreSQL 陷阱排查：长事务冻结 xmin 引发的 MVCC 膨胀风暴与 Autovacuum I/O 瘫痪实战

作者：

ningniu

在

,

某次核心交易链路突发严重告警，PostgreSQL 主库 Load Average 瞬间飙升至 80+，NVMe SSD 的 IOPS 被彻底打满（100% util），核心订单更新接口的 p99 延迟从 5ms 直接恶化到 3000ms 以上，业务几乎处于熔断边缘。

结论先行：这是一起典型的由开发侧“防御性代码”缺失引发的内核级雪崩。一个低频的 BI 抽数 Python 脚本在开启事务后，因遇到未捕获的异常而挂起，导致连接池中残留了一个长达 72 小时的 idle in transaction（空闲事务）。这个幽灵连接死死卡住了 PostgreSQL 的全局 xmin（最老活跃事务ID）水位线。在这 3 天里，核心订单表经历数千万次 UPDATE，由于 xmin 冻结，Autovacuum 无法清理任何死元组（Dead Tuples），导致一张原本 5GB 的表膨胀到了 80GB。当监控系统触发阈值，运维手动 kill 掉该幽灵连接的瞬间，积压的 Autovacuum 进程如饿狼般扑向这 75GB 的垃圾数据，引发了灾难性的 I/O 读写风暴。

最终救火操作：立即调整 autovacuum_vacuum_cost_limit 降低清理 I/O 速率，并在线使用 pg_repack 重组表空间碎片。

案发现场与底层逻辑

排查过程异常简单但令人窒息。登录数据库，敲下第一条排查 SQL：

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

结果赫然显示一个持续了 3 days 02:14:15 的空闲事务。

为什么一个没有任何读写动作的空闲连接，能把数据库逼到 OOM 甚至 I/O 瘫痪的绝境？这必须从 PostgreSQL 的 MVCC（多版本并发控制）实现机制说起。

不同于 MySQL (InnoDB) 将 Undo Log 存放在独立的表空间，PostgreSQL 采用了“Append-Only”式的 MVCC 设计。每次对一行数据进行 UPDATE，PG 内核并不会覆盖原数据，而是将其标记为不可见（设置 xmax），并在堆表（Heap Table）中插入一行新版本的数据。

为了实现快照隔离（Snapshot Isolation），PG 必须保留那些“可能被当前活跃事务读取”的旧版本数据。Autovacuum 进程在决定是否物理清理一行死元组时，判断依据是：该行数据的 xmax（删除它的事务ID）是否小于当前系统所有活跃事务中最小的那个 xmin。

由于那个挂起的 BI 抽数脚本死死咬住了 3 天前的 xmin，这 3 天内产生的所有历史数据版本，对 Autovacuum 来说都是“不可触碰”的。于是，系统只能眼睁睁看着堆表无限制膨胀，不仅消耗大量磁盘，更致命的是污染了 shared_buffers：业务正常的全表扫描或范围查询，不得不把海量的无用死元组读入内存，导致 Buffer Cache 命中率雪崩。

致命的“按下葫芦浮起瓢”：Autovacuum I/O 风暴

当确认是长事务作祟后，通常的操作是 SELECT pg_terminate_backend(pid); 杀掉连接。但真正的灾难往往发生在此时。

长事务被清理，全局 xmin 瞬间推进，原本被冻结的 75GB 死元组瞬间变成了“可回收垃圾”。此时，一直处于休眠或空转状态的 Autovacuum Worker 立即被唤醒，开始对严重膨胀的表执行 Vacuum 扫描。

由于前期有同学为了“加快常规清理速度”，将 autovacuum_vacuum_cost_limit 从默认的 200 激进调大到了 10000，且 autovacuum_vacuum_cost_delay 设为了 0。这就导致 Autovacuum 进程在扫描那 75GB 数据时，几乎没有任何限流（Throttling），直接跑满了底层存储的吞吐带宽。

普通 Vacuum 会产生大量的随机读（扫描表页面和索引页面）以及写入（更新 FSM 空间映射表和 VM 可见性映射表，并产生相应的 WAL 日志）。正常的业务读写被这股突如其来的 I/O 洪流无情碾压，最终引发了 Load 飙升和 QPS 熔断。

防御性配置与最佳实践

把数据库的生死存亡交由业务代码的严谨性来保证，是运维架构的失职。针对此类 MVCC 膨胀与 Vacuum 陷阱，必须在数据库层面实施强制的防御性配置。

1. 强制斩断长事务（核心防线） 在 postgresql.conf 中必须配置以下参数，绝不允许无限期的空闲事务存在。

# 终止超过 60 秒一直处于 idle in transaction 状态的会话
idle_in_transaction_session_timeout = 60000 
# 限制单个语句的最大执行时间（防慢查询打爆 CPU）
statement_timeout = 30000

2. 精细化控制 Autovacuum 的 I/O 成本 不要试图关闭 Autovacuum，也不要无脑调大参数。Vacuum 应该像温水煮青蛙一样持续在后台运行。

# 默认 200 太小，10000 太大，通常建议根据 IOPS 能力设为 1000-2000
autovacuum_vacuum_cost_limit = 2000
# 给予每次清理后短暂的暂停，避免连续霸占 I/O
autovacuum_vacuum_cost_delay = 2ms

3. 监控 oldest_xmin 与死元组率 常规的 CPU 和内存监控无法提前预警 MVCC 膨胀。必须将 pg_stat_user_tables.n_dead_tup（死元组数）和 age(datfrozenxid) 接入 Prometheus。

此外，需要明白一个残酷的事实：普通的 VACUUM 操作只能把空间标记为可用，更新 FSM 表（Free Space Map），供后续 INSERT/UPDATE 复用，它绝对不会将物理磁盘空间还给操作系统。如果表已经膨胀到了 80GB，常规 VACUUM 跑完，表文件依然是 80GB。要缩减物理文件大小，只能使用锁定全表的 VACUUM FULL，或者在生产环境使用非阻塞工具 pg_repack 或 pg_squeeze。

排查清单：PostgreSQL 膨胀与 I/O 突增速查

  1. 查杀空闲长事务： 定位并清理：SELECT pid, pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle in transaction' AND state_change < now() - INTERVAL '5 minutes';

  2. 确认表级膨胀率（死元组占比）： 使用内置统计视图：SELECT relname, n_live_tup, n_dead_tup, (n_dead_tup::float / (n_live_tup + n_dead_tup + 1)) * 100 AS dead_tup_ratio FROM pg_stat_user_tables ORDER BY dead_tup_ratio DESC LIMIT 5;

  3. 排查复制槽（Replication Slot）残留： 除了长事务，废弃的复制槽也会冻结 xmin 和 WAL。检查并清理：SELECT slot_name, plugin, slot_type, active, age(xmin) FROM pg_replication_slots;

  4. 抓取当前 Vacuum 进度与 I/O 开销： 查看 pg_stat_progress_vacuum 视图，确认当前正在执行清理的表，以及处于哪个扫描阶段（如 scanning heap 或 vacuuming indexes）。

更多文章