阮胜昌的博客-Linux&MySQL数据库运维

你好,我是昌哥,进免费技术交流群或咨询加微信: rscpass

一、前言：一个容易被忽视的"刹车片"

在 PostgreSQL 的日常运维中，最容易被忽视、却又最能影响数据库性能的隐藏参数之一，就是 `autovacuum_vacuum_cost_delay`。

这个参数就像汽车的"刹车片"——它决定了 autovacuum 在工作时"踩多重的刹车"。踩得太重，autovacuum 几乎原地不动，死元组堆积如山，表膨胀、性能暴跌；踩得太轻，autovacuum 又可能霸占磁盘 I/O，把正常业务的查询拖到怀疑人生。

作为一名常年处理数据库疑难杂症的 DBA，我在无数次"表突然变慢"的救援现场，最终定位到的根因都指向了这个参数。本文将带你从原理到实践，彻底搞懂这个参数。

二、参数确认：它确实存在

先回答第一步的确认问题：`autovacuum_vacuum_cost_delay` 这个参数是**真实存在**的。

它的"身世"如下：

- 引入版本：PostgreSQL 8.1，几乎与 autovacuum 守护进程一同诞生

- 参数类型：浮点型（real）

- 取值范围：-1 到 100（单位毫秒）

- 特殊值：-1 表示继承 `vacuum_cost_delay` 的值

- 默认取值：

  - PostgreSQL 12 及以后版本：2 毫秒

  - PostgreSQL 8.3 ~ 11 版本：20 毫秒

- 设置上下文：sighup，即修改 postgresql.conf 后 `SELECT pg_reload_conf()` 即可生效，无需重启

- 支持表级覆盖：可以对单表设置存储参数来覆盖全局配置

确认参数存在，我们继续往下分析。

三、核心原理：PostgreSQL 的"代价刹车"机制

要理解 `autovacuum_vacuum_cost_delay`，必须先搞懂 PostgreSQL 的基于代价的清理延迟（Cost-Based Vacuum Delay）机制。这套机制的核心思想是：**让 VACUUM 不要那么"拼命"，以免影响业务**。

3.1 代价的计算过程

autovacuum 工作进程在扫描和清理表时，会持续累加一个"代价计数器"。这个计数器由三类操作的代价构成：

第一，命中共享缓冲区缓存的页面，每个代价为 1 点。它代表锁定缓冲池、查找共享哈希表、扫描页面内容所消耗的资源。

第二，必须从磁盘读取的页面，每个代价为 10 点。这比缓存命中高出一个数量级，因为多了从磁盘读取数据的开销。

第三，被修改并变脏的页面，每个代价为 20 点。这是代价最高的操作，因为后续需要把这些脏页刷回磁盘。

3.2 刹车的工作流程

整个"代价刹车"的工作流程是这样的：

第一步，autovacuum 开始扫描表，每处理一个页面就按规则累加代价。

第二步，当累计代价超过 `autovacuum_vacuum_cost_limit`（默认 -1，即继承 `vacuum_cost_limit`，默认 200）时，工作进程进入"休眠"。

第三步，休眠的时间长度，就是由 `autovacuum_vacuum_cost_delay` 决定的。休眠结束后，代价计数器清零，重新开始累加。

这个"干活—计数—睡觉—清零"的循环周而复始，直到整个表清理完毕。

3.3 吞吐量估算

理解了上面的机制，我们可以估算出 autovacuum 的清理吞吐量：

大致吞吐量 = 代价上限 / 延迟时间 × 每个代价的页面数

以默认配置为例：200 代价 / 2 毫秒 = 每秒约 10 万代价单位。换算成页面，大约相当于每秒 800MB 的缓存命中读取、400MB 的磁盘读取，或者 40MB 的脏页写入。

看起来不算慢？但请注意，这是理想权重下的理论值。实际生产环境中，如果延迟时间设置不当，这个数字会断崖式下跌。

四、版本演变：从 20 毫秒到 2 毫秒的跨越

这个参数的默认值经历过一次重要的变革，理解这次变革对运维至关重要。

4.1 旧时代的 20 毫秒

在 PostgreSQL 11 及之前版本，默认值是 20 毫秒。这个取值反映了 2000 年代中后期主流的存储硬件水平——当时机械硬盘（HDD）是绝对主力，20 毫秒的延迟是合理的保守策略。

但问题是，这个默认配置一直延续到了 SSD 甚至 NVMe 时代。很多 DBA 在做版本升级时，沿用旧的配置文件，导致集群依然跑在 20 毫秒的"古董"延迟下。

4.2 PostgreSQL 12 的十倍加速

PostgreSQL 12 将默认值从 20 毫秒大幅降低到 2 毫秒，整整提升了 10 倍的激进程度。这一改动承认了存储硬件的进化：SSD 和 NVMe 的随机 I/O 能力远超机械硬盘，过长的延迟已经成为性能瓶颈而非保护措施。

**重要提醒**：如果你的 PostgreSQL 是从 11 或更早版本通过 `pg_upgrade` 升级而来，且沿用了旧的 postgresql.conf，那么你的 `autovacuum_vacuum_cost_delay` 可能依然是 20 毫秒。这是我在生产环境排查中遇到最多的"隐形炸弹"之一。

五、参数优化的建议

5.1 第一步：检查当前配置

优化之前，先摸清家底。执行以下查询查看当前所有与代价延迟相关的参数：

SELECT name, setting, unit
FROM pg_settings
WHERE name IN (
  'autovacuum_vacuum_cost_delay',
  'autovacuum_vacuum_cost_limit',
  'vacuum_cost_delay',
  'vacuum_cost_limit',
  'vacuum_cost_page_hit',
  'vacuum_cost_page_miss',
  'vacuum_cost_page_dirty'
)
ORDER BY name;

5.2 第二步：根据存储类型调整延迟

如果你的存储是 NVMe SSD，建议将延迟设置为 1 毫秒甚至 0（完全不延迟）。在 NVMe 上，哪怕 2 毫秒的延迟都是保守的，autovacuum 完全有能力全速运行而不影响业务。

如果你的存储是 SATA SSD，2 毫秒到 5 毫秒是合理的取值区间，这是一个兼顾清理效率和业务响应速度的甜点区。

如果你的存储是传统机械硬盘（HDD），建议保持在 10 毫秒到 20 毫秒。HDD 的随机 I/O 能力有限，过短的延迟会让 VACUUM 挤占磁盘带宽，反而拖慢一切。

如果你的存储是云盘，比如阿里云 ESSD 或腾讯云 CBS，需要根据具体的 IOPS 和吞吐配额来定。一般来说 2 毫秒是安全的起点，再通过监控数据逐步微调。

5.3 第三步：同步调整代价上限

只调延迟不调代价上限，就像只松刹车不给油，效果有限。建议将 `autovacuum_vacuum_cost_limit` 从默认的 200 提升到 1000 或 2000。

注意，这个值是在所有运行中的 autovacuum 工作进程之间按比例分配的。如果你同时调整了 `autovacuum_max_workers`，那么代价上限也要相应同比提升，否则每个工作进程分到的预算反而变少了。

5.4 第四步：表级细粒度覆盖

对于特别大的"热表"，可以在表级别进行覆盖，让这张表享受更激进的清理策略，而全局配置保持不变：

ALTER TABLE orders SET (
  autovacuum_vacuum_cost_delay = 1,
  autovacuum_vacuum_cost_limit = 2000
);

这种方式的好处是：不需要修改全局配置，不影响其他表，也不需要重启或 reload。

5.5 推荐配置模板

以下是一套基于存储类型的推荐配置模板，可直接写入 postgresql.conf：

NVMe SSD 环境：

autovacuum_vacuum_cost_delay = 1
autovacuum_vacuum_cost_limit = 2000
autovacuum_max_workers = 4

SATA SSD 环境：

autovacuum_vacuum_cost_delay = 2
autovacuum_vacuum_cost_limit = 1000
autovacuum_max_workers = 3

HDD 或云盘环境：

autovacuum_vacuum_cost_delay = 10
autovacuum_vacuum_cost_limit = 500
autovacuum_max_workers = 2

修改后执行 `SELECT pg_reload_conf();` 使配置生效。

六、参数避坑的方法

6.1 坑一：从旧版本升级后延迟过大

这是最常见的坑。从 PostgreSQL 11 及之前版本升级到 12 及以上版本时，如果你是通过 `pg_upgrade` 迁移，并且沿用了旧的配置文件，那么 `autovacuum_vacuum_cost_delay` 的值依然是 20 毫秒，而不是新版本的 2 毫秒。

**避坑方法**：升级完成后，第一时间检查这个参数。执行 `SHOW autovacuum_vacuum_cost_delay;` 确认当前生效值。如果不是预期的数值，立即修改配置文件并 reload。

6.2 坑二：延迟过高导致 autovacuum 形同虚设

当 `autovacuum_vacuum_cost_delay` 设置为 20 毫秒或更高，且表有大量死元组时，autovacuum 工作进程大部分时间都在"睡觉"，清理进度几乎为零。

判断方法：间隔一分钟执行两次以下查询：

SELECT pid, relid::regclass AS table_name, phase,
       heap_blks_scanned, heap_blks_vacuumed, heap_blks_total
FROM pg_stat_progress_vacuum;

如果两次查询结果中 `heap_blks_vacuumed` 几乎没有变化，那么代价限速就是你的"罪魁祸首"。

**避坑方法**：按照第五章的建议，降低延迟并提升代价上限。

6.3 坑三：延迟过低导致业务抖动

与坑二相反，如果将延迟设置为 0，autovacuum 会全速运行。这在存储性能强劲时没问题，但在共享存储或 I/O 带宽紧张的云环境中，可能导致磁盘 I/O 被打满，正常业务查询出现明显的延迟毛刺。

**避坑方法**：不要一步到位设成 0。先从 2 毫秒开始，通过监控系统观察磁盘 I/O 利用率、业务 P99 延迟等指标，逐步微调。如果业务出现抖动，适当回调延迟值。

6.4 坑四：代价上限与工作进程数不匹配

很多 DBA 提升了 `autovacuum_vacuum_cost_limit`，同时也增加了 `autovacuum_max_workers`，但没有意识到代价上限是在所有工作进程之间分配的。结果每个工作进程实际可用的预算反而减少了，autovacuum 整体效率不升反降。

**避坑方法**：记住一个公式——单工作进程预算 = 总代价上限 / 工作进程数。如果你把工作进程数从 3 提升到 6，那么代价上限也应该从 1000 提升到 2000，才能保证每个进程分到相同的预算。

6.5 坑五：忽略了 -1 的继承语义

`autovacuum_vacuum_cost_delay` 的默认值是 2，但 `autovacuum_vacuum_cost_limit` 的默认值是 -1。这个 -1 意味着它继承的是 `vacuum_cost_limit` 的值（默认 200）。

很多人在调优时只关注 `autovacuum_vacuum_cost_delay`，却忘了 `autovacuum_vacuum_cost_limit` 可能还在用默认的 200。延迟降下来了，但每个周期的预算依然很小，效果大打折扣。

**避坑方法**：两个参数必须配套调整，要么都显式设置，要么确认继承的值符合预期。

6.6 坑六：多数据库集群的启动间隔

在多租户或 SaaS 架构中，如果 PostgreSQL 集群里有几十上百个数据库，`autovacuum_naptime` 的默认 60 秒会导致每个数据库的实际检查间隔被拉长。这种情况下，即便代价延迟调得再合理，autovacuum 的调度频率本身就是瓶颈。

**避坑方法**：对于多数据库集群，将 `autovacuum_naptime` 从 60 秒降低到 15 秒或 30 秒。

七、生产环境最佳配置建议

7.1 通用黄金法则

经过大量生产环境的实战验证，我总结出以下黄金法则：

第一，存储决定下限。NVMe 用 1 毫秒，SATA SSD 用 2 毫秒，HDD 用 10 到 20 毫秒。这条法则适用于 90% 的场景。

第二，代价上限和延迟要配套。延迟降低到原来的几分之一，代价上限就要提升到原来的几倍，两者必须同步调整。

第三，工作进程数要与代价上限成正比。每个工作进程应该分到至少 500 到 1000 的代价预算。

第四，永远不要在表级别设置 `autovacuum_enabled = false` 后忘记恢复。这是"自杀式"操作，半年后你会发现自己面对一张死元组占比 80% 的表欲哭无泪。

7.2 分阶段调优策略

第一阶段——摸底期：先记录当前配置和各项监控指标（死元组数量、autovacuum 运行时间、磁盘 I/O 利用率），建立基线。

第二阶段——保守调整期：将延迟从当前值减半（比如从 20 毫秒降到 10 毫秒），代价上限翻倍（比如从 200 提到 400），观察一周。

第三阶段——精细优化期：根据第二阶段的监控数据，逐步微调到目标值。如果磁盘 I/O 还有余量、死元组清理跟不上，就继续降低延迟、提高上限；如果出现业务抖动，就适当回调。

第四阶段——长期监控期：将关键指标接入监控系统（如 Prometheus + Grafana），设置告警。关注 `pg_stat_user_tables.n_dead_tup`、`last_autovacuum`、`last_autoanalyze` 等指标。

7.3 应急场景：表膨胀后的快速处理

当你发现某张表的死元组已经堆积到影响性能时，可以按以下步骤快速处理：

第一步，对该表执行手动 VACUUM ANALYZE 清理存量死元组：

VACUUM ANALYZE VERBOSE public.orders;

第二步，临时提升该表的 autovacuum 清理力度，使用表级存储参数覆盖：

ALTER TABLE public.orders SET (
  autovacuum_vacuum_cost_delay = 1,
  autovacuum_vacuum_cost_limit = 2000
);

第三步，清理完成后，根据实际情况决定是否保留表级覆盖。如果这张表是持续的热点表，建议保留；如果只是偶发情况，可以恢复全局默认：

ALTER TABLE public.orders RESET (
  autovacuum_vacuum_cost_delay,
  autovacuum_vacuum_cost_limit
);

7.4 监控指标清单

以下是需要长期监控的关键指标：

死元组数量是衡量 autovacuum 是否跟得上写入负载的核心指标。建议对每张大表设置告警阈值，比如死元组超过总行数的 20% 就告警。

`pg_stat_progress_vacuum` 视图可以实时查看正在进行的 VACUUM 操作的进度，是排查 autovacuum "卡住"问题的利器。

磁盘 I/O 利用率是判断延迟设置是否过低的依据。如果 I/O 利用率长期在 80% 以上且业务有抖动，可能需要适当提高延迟。

业务查询 P99 延迟是最终衡量标准。任何参数调整都要以保证业务延迟稳定为前提。

八、总结

`autovacuum_vacuum_cost_delay` 是 PostgreSQL 性能调优中一个"四两拨千斤"的参数。它看似只是控制休眠时间的一个小数，实际上直接决定了 autovacuum 的清理吞吐能力，进而影响表的膨胀程度、查询性能和整个数据库的健康状态。

记住以下要点：

- 默认 2 毫秒（PostgreSQL 12+），从旧版本升级务必检查是否被设成了 20 毫秒

- NVMe 上可以设为 1 毫秒甚至 0，HDD 上保持 10 到 20 毫秒

- 延迟和代价上限必须配套调整

- 代价上限要在工作进程之间分配，进程数增加时要同比提升上限

- 优先使用表级存储参数做精细化控制，避免全局一刀切

- 调优必须有监控数据支撑，凭感觉调参是大忌

希望这篇文章能帮助你在 PostgreSQL 的运维路上少踩一个坑。如果觉得有用，欢迎转发给身边的朋友，一起学习，共同进步！

字里行间，幸得你驻足品读。我是昌哥，欢迎关注与留言，共赴一场思想的碰撞。

技能提升|培训认证|数据救援|运维保障 找昌哥 微信：rscpass

-----------------------END-----------------------

各大平台都可以找到我：

————————————————————

公众号：昌哥知识星球

技术博客:http://www.linuxmysql.com

墨天轮：https://www.modb.pro/u/427810

CSDN ：https://blog.csdn.net/rscpass

51CTO: https://blog.51cto.com/u_16068254

博客园：https://home.cnblogs.com/u/rscpass

知乎:https://www.zhihu.com/people/shukuinfo

掘金：https://juejin.cn/user/2801995051703454

百家号：https://author.baidu.com/home/1780697309880431

作者：阮胜昌

拥有:MySQL8.0 OCP、Oracle OCP、TIDB PCTA/PCTP/PCSD、Kingbase KCP,软考中级数据库系统工程师、RHCE7.0等行业认证

擅长主流数据库MySQL、Oracle、PostgreSQL的备份恢复,SQL调优、监控运维、故障应急处理等

可提供的技术服务：

1.数据库故障处理/疑难杂症远程支援

2.MySQL/PG/Oracle/SQLSERVER数据库技术服务

欢迎关注我的博客:http://www.linuxmysql.com 一起学习新知识！

技能提升|培训认证|数据救援|运维保障  微信：rscpass