跳转到主要内容

autovacuum

Autovacuum 通过后台调度 VACUUM 与 ANALYZE 维持 MVCC 表的可用状态。它既是性能机制,也是防止事务号回卷的安全网,并非可有可无的清洁任务。
说明

Fact — 官方简述译文:控制 PostgreSQL 是否运行自动清理启动器。

身份

类型 , bool
上游 pg_settings 类型
Context , sighup
配置 reload 后生效
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Vacuuming / Automatic Vacuuming
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG9.0–19 Beta 3 on on

机制详解

启用后,一个 launcher 在各数据库之间协调多个 worker。Worker 依据累计的表变更统计判断是否执行 VACUUM 或 ANALYZE,因此普通自动清理还依赖 track_counts 开启。

常规触发条件响应插入、更新与删除产生的变更。除此之外,即使关闭本参数,PostgreSQL 仍会在必要时启动防回卷 autovacuum,因为旧事务号或 multixact 回卷会威胁数据正确性。

多数触发阈值与成本参数可通过表级 storage parameter 覆盖。临时表无法由 autovacuum 访问;分区会被正常处理,但分区父表仍可能需要手工 ANALYZE。

调优建议

提示

Advice。 以下建议是工作负载起点,必须用真实测量验证。

场景 建议
OLTP 保持开启。优先按热点表单独调优,并结合死元组、autovacuum 时长、worker 被取消情况和 XID 年龄判断是否需要全局加速。
OLAP 为安全起见保持开启,但应与批量装载窗口协调;大批导入后主动 ANALYZE,需要父表统计时对分区父表单独执行 ANALYZE。
小规格 保持默认开启。若资源紧张,优先减少 worker 或降低特定表的积极程度,不要仅为节省少量后台活动而关闭 launcher。

Pigsty 取值

以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具,并按 PG19 Beta 3 渲染当前 Pigsty 模板;这不表示 Pigsty 当前支持该历史或测试版本。

模板 有效值 与上游 boot 比较 源表达式
OLTP 未修改
OLAP 未修改
CRIT 未修改
TINY 未修改
注意

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 关闭它并不会关闭紧急的防回卷 autovacuum。
  • 普通 autovacuum 决策依赖 track_counts。
  • 长事务和陈旧复制槽可能让 worker 即使成功运行也无法回收旧版本。
  • 仅有分区发生变化时,autovacuum 不会自动分析分区父表。
  • 临时表必须由持有它的会话自行维护。

autovacuum_max_workers · autovacuum_naptime · autovacuum_vacuum_scale_factor · autovacuum_analyze_scale_factor · autovacuum_freeze_max_age · track_counts

参考资料