我正在 AWS RDS PostgreSQL 实例上运行数据仓库。大多数繁重的工作都是在夜间批处理期间完成的，并且我们经常使用截断重建策略，对于大型表（100M 行）也是如此。
这似乎会导致 autovacuum 问题，在夜间批次 2 到 4 之间，前 10 个 SQL 语句中的 7 个是针对大型表的 VACUUM ANALYZE 语句：
它们占用了我的 RDS 系统
并将字节平衡降至 0，之后机器速度大大减慢：
显然，将 VACUUM ANALYZE 推迟到稍后的时间范围（当机器几乎空闲时）会更明智。
阅读一些文档后，我可以想到两种策略来完成此任务：
- 关闭这些大表的 Autovacuum，并安排一个稍后运行 Vacuum 的进程
- 将 设为
autovacuum_cost_delay一个合理的值。因为这通常会推迟 Vacuum 处理（或者可能仅针对这些表将其设置为合理的值）。
然而，在这种情况下，什么是合理的值呢？我读到默认值为 2 毫秒。200ms 应该大多少？10秒？1分钟？60分钟？
我正在寻找一个合理的值来开始测试或其他可以帮助我的建议。
注意。该机器为 2cpu、16GB m6g.large，这些是 autovauccum 相关参数的当前设置：
额外信息
@jjanes是的，它几乎没有达到0的字节平衡，但是，这是我实际上设法实现的一个仔细的平衡。我经常遇到这样的情况：实际上跌到0后需要很长时间才能恢复。例子
然后我的机器也开始增加读/写延迟和 DiskQueueDepth
夜间批量加载涉及很多表（目前约900张），这些表都是在23点到6点30分之间通过作业加载/转换的，最繁忙的时间是2点到4点。许多桌子都很小，只有少数桌子相当大。
@jjanes & @frank-heikens，哪个后续版本确实有所不同？这是从 14 迁移到 15 之前和之后的情况的两张截图： 之前： 之后
：
更新实施了@Laurence Albe 的建议。观察结果：
字节平衡更好：
数据库负载更加均匀：
您应该禁用
autovacuum_vacuum_insert_threshold有问题的表：那么加载数据就不会触发autovacuum。确保
VACUUM在加载完成后和开始查询表之前在表上触发显式。TOP SQL 图表没有多大意义。所有真空语句都位于顶部附近，仅仅是由于 Timeout:VacuumDelay（假设两个面板之间的配色方案相同）。这并不表明真空正在遇到问题，也不表明真空是造成这些问题的原因。这一切都表明，真空吸尘器正在试图避免引发问题，但成功程度未知。（可以说，顶级 SQL 图表应该将此类时间排除在排序之外。）
Vacuum 当然会使用大量 IO，但我们没有任何证据表明它是导致问题的原因。完全有可能的是，批量加载本身正在耗尽您的 IO。您说 IO 平衡仅在短时间内达到零，因为您进行了仔细的平衡行为，但如果不知道该行为是什么，则很难用它来归因原因。
您可能需要设置 autovacuum_cost_delay，以便 autovacuum 本身消耗 IO 余额的速度不能快于其充电速度。但我们不知道充值率是多少，你告诉了我们机器类型，但没有告诉我们IO类型。但如果这个水平太低怎么办？您不能只是希望不需要进行有效的清理，您可能需要购买更多的 IO 容量。
如果使用 COPY FREEZE 而不是 INSERT 填充表，则可能会更有效地利用 IO。