PostgreSQL 9.3 Autovacuum配置激进仍无法跟上清理进度

我来帮你拆解这个autovacuum跟不上的问题——这种情况在高写入/删除的活跃表上太常见了，咱们一步步排查和解决：

先搞清楚为什么你的autovacuum没触发/跑不动 #

你已经给表设置了autovacuum_vacuum_threshold = 10000，但死元组到63356还没触发，大概率是这几个原因：

• 触发阈值计算没达标（或者刚达标但autovacuum还没轮到）：autovacuum的触发阈值是 阈值 + 表行数 * 比例因子，你只改了阈值，表级的autovacuum_vacuum_scale_factor还是继承全局的0.05。假设你的表有100万行，那触发阈值是10000 + 1000000*0.05 = 60000，你的死元组63356刚超过一点，可能autovacuum的调度队列还没轮到这个表。
• autovacuum被限速拖垮了：你全局设置的autovacuum_vacuum_cost_delay = 50ms，意味着autovacuum每消耗7000的cost就会暂停50ms。而你的vacuum_cost_page_hit/miss/dirty都设置得很高，导致autovacuum跑几步就停，清理速度赶不上死元组产生的速度。
• 可能有锁阻塞或者worker资源被占满：如果其他长事务持有表的排他锁，或者10个autovacuum worker都被其他表占用，这个表的autovacuum根本启动不了。

立刻能生效的调整方案 #

1. 给目标表设置更激进的autovacuum参数 #

直接修改表级配置，让它更容易触发，且全速清理：

ALTER TABLE veryactivetable SET (
  autovacuum_vacuum_threshold = 5000,       -- 降低触发的基础阈值
  autovacuum_vacuum_scale_factor = 0.02,    -- 降低比例因子，避免大表阈值过高
  autovacuum_vacuum_cost_delay = 0,         -- 取消autovacuum的暂停延迟，让它全速跑
  autovacuum_vacuum_cost_limit = 10000      -- 提高cost限制，减少暂停次数（如果还有延迟的话）
);

2. 排查资源和锁阻塞情况 #

• 检查autovacuum worker是否被占满：

  SELECT count(*) FROM pg_stat_activity WHERE query LIKE '%autovacuum:%';
  

  如果结果接近10，说明其他表在占用worker资源，可以临时调高autovacuum_max_workers。
• 检查是否有锁阻塞autovacuum：

  SELECT * FROM pg_locks 
  WHERE relation = 'veryactivetable'::regclass 
  AND mode = 'ExclusiveLock';
  

  如果有结果，说明有长事务或者DDL操作在占锁，得等它结束或者杀掉对应的进程。

3. 应急手动清理（低峰期执行） #

如果死元组已经影响性能，先手动跑一次清理：

VACUUM ANALYZE veryactivetable;

⚠️ 注意：普通VACUUM只会加共享锁，不会阻塞读写，但如果有长事务未提交，可能会等待；尽量避开业务高峰执行。

长期优化建议 #

如果你的数据库里有多个高活跃表，建议调整全局autovacuum配置（修改postgresql.conf后执行SELECT pg_reload_conf();生效）：

autovacuum_vacuum_cost_delay = 0          -- 全局取消autovacuum的延迟，让清理更高效
autovacuum_vacuum_cost_limit = 10000      -- 提高cost限制
autovacuum_vacuum_scale_factor = 0.02     -- 降低全局比例因子，让小表也能及时触发

另外，开启log_autovacuum_min_duration = 0后，一定要定期查看pg_log里的autovacuum日志，能帮你快速定位为什么某个表没被清理——比如日志里会显示autovacuum启动、暂停、完成的时间，以及是否被中断。

内容的提问来源于stack exchange，提问作者Toomuchcode