postgresql中vacuum持续运行且i/o升高，主因是长事务/复制槽滞留、autovacuum成本限制过低、大表触发阈值失当、freeze风暴临近或rds 14及以下stats collector磁盘写入。需依次检查长事务与复制槽、调高autovacuum_vacuum_cost_limit、为大表设更低autovacuum_vacuum_scale_factor、监控并手动freeze高龄表、rds 14及以下临时关闭track_counts并升级至15+。
如果您观察到PostgreSQL中vacuum进程持续运行并引发I/O显著升高，则很可能是由于死元组积压、参数配置失当或长事务阻塞等底层机制被持续触发。以下是解决此问题的步骤：
一、检查长事务与复制槽滞留
长事务或未释放的复制槽会锁定旧快照（backend_xmin），阻止autovacuum清理死元组，导致其反复扫描同一张表甚至触发强制freeze扫描，从而产生大量随机I/O。
1、执行SQL查询是否存在长时间未结束的事务：
SELECT pid, now() - backend_start AS duration, state, query FROM pg_stat_activity WHERE state = 'active' AND now() - backend_start > interval '5 minutes';
2、检查逻辑复制槽是否滞留：
SELECT slot_name, plugin, slot_type, database, active, xmin, catalog_xmin, restart_lsn FROM pg_replication_slots ORDER BY active, xmin;
3、对已离线且不再需要的复制槽执行清理：
SELECT pg_drop_replication_slot('slot_name');
二、调整autovacuum成本限制参数
默认autovacuum_vacuum_cost_limit=200过低，使vacuum进程无法高效完成清理，被迫拉长时间窗口、多次唤醒，加剧I/O毛刺；提高该值可加快单次清理吞吐，缩短整体执行周期。
1、临时提升当前会话的成本上限（仅限调试）：
SET autovacuum_vacuum_cost_limit = 2000;
2、在RDS控制台或postgresql.conf中持久化修改：
autovacuum_vacuum_cost_limit = 2000
3、同步调高关联阈值以避免频繁触发：
autovacuum_vacuum_cost_delay = 10ms
三、优化大表的表级autovacuum策略
全局scale_factor（如0.2）对千万级以上大表不适用——需达数百万死元组才触发vacuum，易造成严重膨胀与集中式I/O冲击；为大表单独设置更低的触发阈值，可实现更平滑、分散的清理节奏。
1、识别高死元组比例的大表：
SELECT schemaname, relname, n_dead_tup, n_tup_ins - n_tup_del AS net_inserts, pg_size_pretty(pg_total_relation_size(oid)) FROM pg_class c JOIN pg_stat_all_tables t ON c.oid = t.relid WHERE c.relkind = 'r' AND n_dead_tup > 100000 ORDER BY n_dead_tup DESC LIMIT 10;
2、为指定大表设置更敏感的vacuum触发条件：
ALTER TABLE public.large_log_table SET (autovacuum_vacuum_scale_factor = 0.01, autovacuum_vacuum_threshold = 5000);
3、确认参数已生效：
SELECT relname, reloptions FROM pg_class WHERE relname = 'large_log_table';
四、定位并干预freeze风暴
当表的age(relfrozenxid)接近autovacuum_freeze_max_age（默认2亿）时，系统将强制执行全表扫描式freeze，跳过visibility map直接读取所有数据页，引发瞬时IOPS飙升；该操作不可中断，且WAL写入量剧增。
1、检测高龄表（age > 1.5亿）：
SELECT age(relfrozenxid), relname, schemaname, pg_size_pretty(pg_total_relation_size(oid)) FROM pg_class c JOIN pg_stat_all_tables t ON c.oid = t.relid WHERE age(relfrozenxid) > 150000000 AND relkind = 'r' ORDER BY age(relfrozenxid) DESC;
2、对关键高龄表执行手动freeze（避开业务高峰）：
VACUUM FREEZE VERBOSE public.critical_table;
3、检查freeze相关日志确认是否发生强制清理：
grep "aggressive vacuum\|to prevent wraparound" $PGDATA/log/*.log
五、禁用stats collector进程（仅限RDS PostgreSQL 14及以下）
在RDS PostgreSQL 14及以下版本中，autovacuum worker频繁更新统计信息会持续向stats collector进程发送数据，后者将统计写入磁盘文件，形成稳定I/O源；该行为在表数量多、更新频繁时尤为明显。
1、确认当前版本：
SHOW server_version;
2、若为14或更低版本，启用短期缓解措施：
SET track_counts = off;
3、长期方案必须升级至RDS PostgreSQL 15+，因其已将统计信息移入共享内存，完全移除stats collector磁盘IO路径。
