跳转到主要内容

vacuum_cost_delay

vacuum_cost_delay:设置清理成本延迟(毫秒)。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0 ms,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置清理成本延迟(毫秒)。

身份

类型 , real
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 , ms
原始单位
范围 , 0100
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Vacuuming / Cost-Based Vacuum Delay
上游分类
最后 boot 值 , 0
0 ms

生命周期

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

默认值变迁

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

机制详解

设置清理成本延迟(毫秒)。它可在会话级修改,因此不同会话可能采用不同的行为。

VACUUM 按页命中、未命中和弄脏操作累加虚拟成本;余额达到 vacuum_cost_limit 后按 vacuum_cost_delay 休眠并重置。该模型是粗粒度 I/O 节流,不是精确带宽上限;防回卷 failsafe 会绕过节流。

应把 vacuum_cost_delay 与 vacuum_cost_limit、vacuum_cost_page_hit、vacuum_cost_page_miss 一起监控和变更。先在对应角色与真实负载上验证,再按其 user context 选择会话修改、reload 或 restart;历史默认值并不等于当前有效值。

调优建议

提示

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

场景 建议
OLTP 用 autovacuum 时长、死元组增长和前台 I/O 延迟共同调 vacuum_cost_delay;优先表级覆盖热点表,避免全局节流让清理永远追不上。
OLAP 在装载后维护窗口可提高成本额度或缩短延迟,但要验证扫描吞吐不会挤占查询/导入;failsafe 触发说明常态策略已失效。
小规格 保持温和默认;若磁盘很慢,降低并发或给单表覆盖通常比无限增大 delay 更可控。

Pigsty 取值

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

模板 有效值 与上游 boot 比较 源表达式
OLTP 20ms 不同于 boot 值 20ms
OLAP 10ms 不同于 boot 值 10ms
CRIT 20ms 不同于 boot 值 20ms
TINY 20ms 不同于 boot 值 20ms
注意

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 = 20ms (dcs);OLAP: PG9.0–19 Beta 3 = 10ms (dcs);CRIT: PG9.0–19 Beta 3 = 20ms (dcs);TINY: PG9.0–19 Beta 3 = 20ms (dcs)。 建议(待人工复核)——编辑推断(待维护者人工复核):该选择看起来意在节流手工 VACUUM 及继承它的 autovacuum I/O,并让高吞吐 OLAP 使用更短延迟;发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。

常见坑

  • 只改全局值,忽略表级 storage parameter 覆盖。
  • 把 reltuples 与累计变更统计当作精确实时计数。
  • 不看长事务、复制槽和 worker 饱和就责怪阈值。
  • 用降低维护频率换取短期平静,最终进入防回卷 failsafe。

vacuum_cost_limit · vacuum_cost_page_hit · vacuum_cost_page_miss · vacuum_cost_page_dirty · autovacuum_vacuum_cost_delay · autovacuum_vacuum_cost_limit

参考资料