我正在 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 的建议。观察结果: