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

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

一、前言：一个被低估的"油门踏板"

PostgreSQL 的 autovacuum（自动清理）是数据库稳定运行的核心守护机制，它负责回收死元组（dead tuples）、更新统计信息、冻结事务 ID 防止回卷。可以说，autovacuum 健不健康，直接决定了一套 PostgreSQL 实例能不能长期稳定运行。

但在生产环境中，DBA 们经常遇到两种截然相反的困境：

一种是 autovacuum 太"温柔"，死元组越积越多，表膨胀严重，查询越来越慢，最后只能靠手动 `VACUUM FULL` 或 `pg_repack` 来救命；

另一种是 autovacuum 太"暴力"，在业务高峰期疯狂刷脏页，IO 打满、CPU 飙升、业务请求排队超时，报警电话响个不停。

造成这两种极端现象的幕后推手之一，就是基于成本的 Vacuum 延迟机制（Cost-based Vacuum Delay），而其中最容易被忽视、却又极其关键的参数，就是 autovacuum_vacuum_cost_limit。

这个参数本质上是 autovacuum 的"油门踏板"——它决定了 autovacuum 在每次循环中最多能"消费"多少 I/O 成本，然后必须歇一歇。油门踩太深，会压垮业务；油门踩太浅，清理永远赶不上写入。

本文将从原理、源码逻辑、参数优化、避坑方法到生产环境最佳配置，对这个参数做一次深度拆解，力求让你读完之后，对自己的 PostgreSQL 实例该把油门踩在什么位置，心里有数。

二、参数身份确认：它到底是谁

参数名称：autovacuum_vacuum_cost_limit

参数类型：integer（整数）

取值范围：-1 到 10000

默认值：-1

生效上下文：sighup（意味着修改 postgresql.conf 或 postgresql.auto.conf 后，执行 `SELECT pg_reload_conf();` 即可生效，无需重启实例）

引入版本：PostgreSQL 8.1（这是一个历史悠久、非常成熟的参数，从 8.1 一路延续到最新的 19 版本，行为基本稳定）

作用范围：仅作用于自动触发的 VACUUM 操作（即 autovacuum worker 进程），对人工手动执行的 VACUUM 命令不起作用——手动 VACUUM 使用的是另一套参数 vacuum_cost_limit 和 vacuum_cost_delay。

可覆盖性：这个参数既可以在全局（postgresql.conf / postgresql.auto.conf）层面设置，也可以通过表级存储参数（Storage Parameters）针对单张表单独覆盖。这一点非常重要，它是我们后面"大表单独提速、小表全局限速"策略的基础。

三、核心原理：成本账本与睡觉规则

要真正理解 autovacuum_vacuum_cost_limit，必须先理解 PostgreSQL 的基于成本的 Vacuum 延迟机制。这套机制的运作逻辑，可以用一个"记账—睡觉—清零"的循环来概括。

3.1 三本成本账

PostgreSQL 为 VACUUM 定义了三本"成本账"，分别对应不同类型的页面操作，每本账都有一个默认单价：

第一本账：vacuum_cost_page_hit，默认 1。当一个页面在共享缓冲区（shared buffer cache）中被命中时记 1 分。意思是这个页面不需要读磁盘，代价相对较小。

第二本账：vacuum_cost_page_miss，默认 2。当一个页面不在缓冲区、必须从磁盘读取时记 2 分。多了一次物理 I/O，代价比命中高一点。

第三本账：vacuum_cost_page_dirty，默认 20。这是最关键的一本账。当 VACUUM 修改了一个原本干净的页面，把它弄"脏"了，需要记 20 分。为什么是 20？因为脏页最终需要被刷回磁盘，这里隐含了未来一次额外的物理写 I/O。正是这个 20:1 的差距，决定了 VACUUM 的主要成本来源。

3.2 记账—睡觉—清零的循环

autovacuum worker 进程在扫描页面时，每处理一个页面，就按上面的规则把对应的成本分数累加到一本"内部计数器"里。

当这本账的累计成本达到 autovacuum_vacuum_cost_limit 所设定的上限时，worker 进程就会暂停下来，睡一觉。这一觉睡多久，由另一个参数 autovacuum_vacuum_cost_delay 决定（默认 2 毫秒，早期版本如 9.5 之前默认是 20 毫秒）。

睡醒之后，内部计数器清零，worker 继续干活，开始下一轮记账。

这套机制的设计初衷非常朴素：让维护命令（VACUUM/ANALYZE）不要跑得太快，以免对正常的业务数据库活动造成显著的 I/O 干扰。 换句话说，autovacuum 被设计成一个"懂事"的后台进程，宁可自己慢一点，也不去抢业务的资源。

3.3 一个容易被忽略的细节：多人分账

官方文档里有一段话非常关键，也是很多 DBA 踩坑的地方：

> 注意，当有多个 autovacuum worker 同时运行时，这个上限值会按比例分配给每个 worker，使得所有 worker 的 limit 之和不超过该变量的值。

举个具体的例子。假设 autovacuum_vacuum_cost_limit 设为 1000，autovacuum_max_workers 默认是 3。那么当 3 个 worker 同时在跑时，每个 worker 实际拿到的 limit 大约是 1000 的三分之一，也就是约 333。如果只有 1 个 worker 在跑，它才能独享完整的 1000。

这个"分账"逻辑意味着：你以为给 autovacuum 配了一个 1000 的额度，实际上在 worker 并发时，每个 worker 的吞吐量被摊薄了。如果你不把这个特性算进去，就容易出现"明明设了不小的 limit，autovacuum 却还是慢吞吞"的困惑。

3.4 特殊场景：关键锁持有期间的例外

还有一个值得注意的细节。文档明确指出，当进程持有关键锁（critical locks）时，必须尽快完成操作，此时不会触发基于成本的延迟。因此，实际累计成本有可能远远超出设定的 limit。为了避免由此产生无意义的长时间延迟，PostgreSQL 对实际延迟做了一个封顶：实际延迟 = vacuum_cost_delay × (累计余额 / vacuum_cost_limit)，但最大不超过 vacuum_cost_delay × 4。

这个兜底机制保证了即使在极端情况下，VACUUM 也不会被"罚站"太久。

四、默认值 -1 的真相：继承关系

autovacuum_vacuum_cost_limit 的默认值是 -1，这个 -1 不代表"没有限制"，而是代表"我什么都不管，直接沿用 vacuum_cost_limit 的值"。

也就是说，默认情况下，autovacuum 的成本上限是由 vacuum_cost_limit 这个参数决定的，而 vacuum_cost_limit 的默认值是 200。

这是一个非常保守的默认值。200 的成本上限，意味着 worker 每累计 200 分就要睡 2 毫秒（默认 delay）。对比一下：每弄脏一个页面就是 20 分，弄脏 10 个页面就到上限了。然后睡 2 毫秒，再继续。

这个默认配置的目标很明确——优先考虑不干扰业务，而不是清理效率。它适用于大多数"写入量不大、对后台清理敏感度较高"的通用场景。但放到今天的高并发、大写入、大表众多的生产环境里，这个默认值往往过于保守，导致 autovacuum 完全跟不上写入速度，最终引发表膨胀、事务 ID 逼近回卷临界点等一系列连锁问题。

五、参数优化的方法论：从拍脑袋到看数据

调优 autovacuum_vacuum_cost_limit 不能靠猜，更不能照抄网上的"万能配置"。正确的做法，是从实例硬件资源出发，逐步推导出一个合理的起点，再结合监控数据持续微调。

5.1 第一步：先调整 cost delay，再谈 cost limit

这是很多 DBA 本末倒置的地方。vacuum_cost_delay 和 vacuum_cost_limit 是"睡眠时长"和"账单上限"的关系，必须一起看。

成本上限的计算公式，本质上可以推导出一个理论吞吐量：

理论每秒 I/O 成本 = cost_limit ÷ cost_delay

比如默认配置：200 ÷ 0.002秒 = 100,000 成本单位/秒。

如果我们把 cost_delay 调小到 1 毫秒，limit 保持 200，那么吞吐量就是 200,000 成本单位/秒，效率翻倍，同时单次睡眠更短、对业务更"细腻"。

如果保持 cost_delay = 2 毫秒，把 cost_limit 提到 1000，吞吐量变成 500,000 成本单位/秒。

这两种调法的最终效果不同：调小 delay 意味着"更频繁地短睡"，业务抖动更平滑；调大 limit 意味着"一次干更多活再睡"，单轮吞吐量更高但单次睡眠更明显。

5.2 第二步：根据存储类型定基准线

存储的 I/O 能力是设定 cost limit 的核心依据。

机械硬盘（HDD）环境：I/O 吞吐能力有限，而且随机 I/O 性能很差。建议保持相对保守的设定，比如 cost_delay 维持在 2 毫秒，cost_limit 可以设在 200 到 500 之间。原则是宁可 autovacuum 慢一点，也不要让它把本来就捉襟见肘的磁盘 I/O 彻底占满。

SATA/SAS SSD 环境：随机 I/O 性能相比机械盘有数量级的提升。可以把 cost_delay 降到 1 毫秒或 2 毫秒，cost_limit 设到 500 到 1000 的区间，让 autovacuum 的清理速度跟得上中等强度的写入。

NVMe / 企业级高性能 SSD 环境：这类存储的 I/O 能力非常强悍，往往是 CPU 或内存先成为瓶颈，而不是磁盘。此时默认值 -1 会显得极度保守，autovacuum 完全跑不满存储能力。建议把 cost_delay 调低到 1 毫秒甚至更低（注意部分老旧平台对亚毫秒级延迟测量不准，此时应改调 cost_limit），cost_limit 可以直接设到 2000、5000 甚至 10000。

云环境（EBS、云盘等）：云盘通常有 IOPS 和吞吐量的硬性配额上限。这里的关键不是存储多快，而是不要触碰云盘的 IOPS 上限。建议结合云盘的基线 IOPS 和突发 IOPS 能力来设定，cost_limit 可以设在 500 到 2000，并密切监控云监控面板里的 IOPS 使用率，避免 autovacuum 吃光配额导致业务 I/O 被限流。

5.3 第三步：结合 autovacuum_max_workers 做换算

前面提到的"分账"逻辑决定了：你的 cost_limit 必须和 worker 数量一起考虑。

一个简单的推算公式：

单 worker 实际成本预算 = autovacuum_vacuum_cost_limit ÷ 并发 worker 数

如果你把 cost_limit 设成 2000，max_workers 设成 5，那么高峰并发时每个 worker 实际只有 400 的预算，清理速度依然不理想。

所以调优时的正确思路是：先想清楚你希望每个 worker 至少拿到多少预算，再反推 cost_limit 应该设多大。

例如，希望每个 worker 至少有 1000 的预算，预计最多 3 个 worker 并发，那么 cost_limit 就应该设成 3000 左右。

同时提醒一句：autovacuum_max_workers 并不是越大越好。每个 worker 都是一个独立的后端进程，会消耗内存（尤其会影响 maintenance_work_mem 的使用量，每个 worker 都会单独申请一份），并发太高会反向拖累性能。通常 3 到 5 个 worker 是比较合理的区间。

六、参数避坑指南：这些错误千万别犯

在实际运维中，关于这个参数有太多"想当然"的坑，下面逐条列出，帮你提前排雷。

坑一：以为 -1 就是"不限速"

这是最典型的误解。-1 的意思是"继承 vacuum_cost_limit 的默认值 200"，也就是一个相当严格的限速。很多 DBA 看到 -1 就以为 autovacuum 在全力狂奔，结果排查半天发现清理效率极低，元凶就是这个"-1 假象"。

正确做法：要么显式设置 autovacuum_vacuum_cost_limit 为一个合理的具体数值，要么如果你确实想让它"不限速"，应该把 autovacuum_vacuum_cost_delay 设为 0（delay 为 0 会直接禁用基于成本的延迟机制），而不是指望 -1。

坑二：只改 cost_limit，忘了 cost_delay

这两个参数是联动的。如果你的 cost_delay 还是默认的 2 毫秒，光把 cost_limit 从 200 提到 2000，理论上吞吐量确实提升 10 倍，但这个提升完全建立在"睡得更久、干得更多"的节奏上。在某些场景下，把 delay 调小到 1 毫秒、保持较小的 limit，反而能获得更平滑的 I/O 曲线。

正确做法：永远把 cost_limit 和 cost_delay 作为一对参数来调优，不要单独修改其中一个。

坑三：忽略"多 worker 分账"，设的值根本不够分

很多人在 3 worker 的默认配置下把 cost_limit 设为 600，以为每个 worker 有 600 的额度，实际上每个只有 200。

正确做法：设定 cost_limit 时，心里永远要乘上"并发 worker 数"这个系数。

坑四：设了 10000 以为万事大吉

10000 是这个参数的上限。但要注意，上限不等于合理值。如果你的存储根本跑不出那么高的 I/O，或者你的 vacuum_cost_delay 还是 2 毫秒，那么 10000 的 limit 意味着 worker 会一口气干完 10000 成本才睡一次，单次 I/O 峰值可能非常吓人，直接把业务打挂。

正确做法：10000 只适合 NVMe 级别的高端存储，并且要配合足够小的 cost_delay（比如 1 毫秒甚至 0.5 毫秒）使用，让睡眠更频繁、单次冲击更小。

坑五：忘记表级覆盖，搞"一刀切"

全局参数会对所有表生效。但一个库里往往有几十上百张表，小表几 MB，大表几百 GB。用同一套限速策略去套所有表，既不科学也不高效。

正确做法：利用表级存储参数的覆盖能力，对小表用全局保守配置，对真正的大表单独提速。例如对几百 GB 的日志表、流水表，用 `ALTER TABLE big_table SET (autovacuum_vacuum_cost_limit = 2000);` 单独给它开"快速通道"。

坑六：改了参数不生效，以为是参数没用

autovacuum_vacuum_cost_limit 的 context 是 sighup，修改后需要执行 `SELECT pg_reload_conf();` 才能生效。如果你只是改了配置文件却忘了 reload，或者误以为需要重启（其实不需要），就会陷入"参数不生效"的困惑。

正确做法：改完配置后执行 `SELECT pg_reload_conf();`，然后通过 `SHOW autovacuum_vacuum_cost_limit;` 确认当前生效值。

坑七：改了参数就不管了，不监控

调参不是终点，监控才是。如果改完不监控，你根本不知道清理速度到底变快了没有，也不知道有没有对业务造成冲击。

正确做法：调参前后都要监控关键指标，包括但不限于：dead tuples 的积累速率、pg_stat_user_tables 里 n_dead_tup 的变化、autovacuum 单次运行的耗时、磁盘 I/O 利用率、业务端 P99 延迟。

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

下面给出一套经过实践检验的分层配置建议，覆盖不同规模的典型生产场景。需要强调的是，这些只是起始参考值，具体数值必须结合你自己的硬件和业务负载做微调，切忌生搬硬套。

7.1 小型实例（单机、低并发、机械盘或普通 SSD）

适用场景：数据量在百 GB 以内，写入压力不大，对成本控制敏感，对后台清理的干扰比较敏感。

推荐配置：

autovacuum_vacuum_cost_delay = 2ms

autovacuum_vacuum_cost_limit = 200（即保持默认值 -1 的效果，或显式设为 200）

这套配置沿用 PostgreSQL 的保守哲学，优先保证业务稳定，适合对性能不敏感、追求省心的环境。

7.2 中型实例（主流 SSD、中等写入量）

适用场景：数据量在几百 GB 到数 TB，业务有一定写入压力，已经出现轻微表膨胀迹象。

推荐配置：

autovacuum_vacuum_cost_delay = 1ms

autovacuum_vacuum_cost_limit = 500 到 1000

autovacuum_max_workers = 3 到 4

这是最常见的生产配置档位。把 delay 砍半、limit 提到 500 以上，通常能让 autovacuum 的清理速度提升数倍，同时保持对业务的友好度。

7.3 大型实例（NVMe SSD、高并发高写入）

适用场景：数据量在数 TB 以上，写入非常频繁，大表众多，表膨胀是长期困扰。

推荐配置：

autovacuum_vacuum_cost_delay = 1ms 或 2ms（NVMe 下 1ms 通常足够细腻）

autovacuum_vacuum_cost_limit = 2000 到 5000

autovacuum_max_workers = 4 到 5

配合提高 maintenance_work_mem，让每个 worker 的清理更高效

注意：这个档位的 limit 已经相当高了，务必配合监控使用，确保磁盘 I/O 没有被打满。

7.4 超大并发写入场景（适当"放行"）

适用场景：极端高写入负载，autovacuum 无论如何都赶不上死元组生成速度，且磁盘 I/O 能力充裕。

在这种场景下，可以考虑直接"放行"基于成本的延迟机制：

autovacuum_vacuum_cost_delay = 0

把 delay 设为 0 会完全禁用 autovacuum 的基于成本延迟，让 worker 全速运行。这样做的前提是：你的存储 I/O 能力非常强，且能容忍 autovacuum 和业务争抢资源。 这是一种"宁可业务受点影响，也要保住清理速度"的取舍，通常在写入峰值期临时开启，或者配合表级覆盖来精准使用，不建议作为全局长期配置。

7.5 大表加速：表级覆盖的正确姿势

对于库里那几张真正的大表（比如几百 GB 的订单流水、日志记录），全局的 cost_limit 往往不够用。建议对这几张表单独配置：

ALTER TABLE large_log_table SET (autovacuum_vacuum_cost_limit = 2000);

ALTER TABLE large_log_table SET (autovacuum_vacuum_cost_delay = 1);

这样，这几张最需要清理的大表能拿到更高的成本预算、跑得更快，而库里其他小表继续使用全局的保守配置，互不干扰。这是一种非常实用且精细化的调优手段。

7.6 必须配套调整的兄弟参数

单独调 autovacuum_vacuum_cost_limit 往往不够，下面这些参数必须一起看：

autovacuum_vacuum_cost_delay：和它成对调整，缺一不可。

autovacuum_max_workers：控制并发 worker 数，直接影响 limit 的分账结果。

vacuum_cost_page_dirty / vacuum_cost_page_hit / vacuum_cost_page_miss：这三本成本账的单价。如果你的存储特性特殊（比如某些全闪存阵列的读和写成本差异很小），可以适当调低 vacuum_cost_page_dirty 的单价（比如从 20 调到 10），让 VACUUM 的"脏页惩罚"没那么重，从而整体提速。但调整这三兄弟要非常谨慎，建议只在充分测试后再上生产。

maintenance_work_mem：虽然不是直接相关的参数，但直接影响 VACUUM 的效率。给每个 autovacuum worker 更大的 maintenance_work_mem，能让它用更大的内存来维护死亡元组链表，减少重复扫描，从根本上降低对成本限速机制的压力。

八、调优的验证与监控闭环

参数调完不等于结束，必须用数据来验证效果。建议建立这样一个闭环：

第一步：调参前，记录基线。

记录当前死元组的积累速率、autovacuum 运行频率、单次运行耗时、磁盘 I/O 利用率、业务 P99 延迟。这些是后续对比的依据。

第二步：调参后，观察趋势。

重点观察几个指标：

pg_stat_user_tables 里的 n_dead_tup 是否在 autovacuum 运行后明显下降；

last_vacuum 和 last_autovacuum 的时间间隔是否在缩短；

pg_stat_activity 里 autovacuum worker 的运行时长是否更短；

磁盘 IOPS 和 await 是否出现异常飙升。

第三步：业务侧验证。

调参的核心目的有两个——让 autovacuum 跑得更快（业务侧看表膨胀是否缓解、查询是否变快），同时不让业务变慢（业务侧看 P99 延迟、超时率、CPU 和 IO 是否稳定）。两边都要看，缺一不可。

第四步：迭代微调。

一次调到位的情况很少。通常是先设一个保守的起点，观察一两周，再逐步放开 limit，直到找到一个既不引起业务抖动、又能及时清理死元组的平衡点。

九、总结

autovacuum_vacuum_cost_limit 是 PostgreSQL 里一个看似简单、实则内涵丰富的参数。它的本质是 autovacuum 的"油门"——决定了这个后台清理进程每跑多少活就要歇一歇。

理解它的关键，在于理解那三本成本账（page_hit、page_miss、page_dirty）以及"记账—睡觉—清零"的工作循环；用好它的关键，在于理解多 worker 的分账逻辑、与 cost_delay 的联动关系，以及表级存储参数的覆盖能力。

最后再强调一遍核心心法：

不要被 -1 的默认值欺骗，它其实是保守的 200；

cost_limit 和 cost_delay 必须成对被调优，不能单独改一个；

设定 limit 时永远要考虑并发 worker 数的分账效应；

对真正的大表，善用表级覆盖做精准提速；

调参必须有监控闭环，用数据说话，而不是靠感觉。

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