相关疑难解决方法(0)

我试图让 PostgreSQL 积极地自动清空我的数据库。我目前已按如下方式配置自动真空吸尘器：

• autovacuum_vacuum_cost_delay = 0 #关闭基于成本的真空
• autovacuum_vacuum_cost_limit = 10000 #最大值
• autovacuum_vacuum_threshold = 50 #默认值
• autovacuum_vacuum_scale_factor = 0.2 #默认值

我注意到自动真空仅在数据库未加载时才会启动，因此我遇到死元组比活元组多得多的情况。有关示例，请参阅随附的屏幕截图。其中一张表有 23 个活动元组，但有 16845 个死元组等待真空。这太疯狂了！

当测试运行完成并且数据库服务器空闲时，自动真空开始，这不是我想要的，因为我希望自动真空在死元组数量超过 20% 活元组 + 50 时启动，因为数据库已经配置。服务器空闲时的自动真空对我来说是无用的，因为生产服务器预计会在持续时间内达到 1000 次更新/秒，这就是为什么即使服务器负载不足我也需要自动真空运行。

有什么我想念的吗？如何在服务器负载较重时强制运行自动吸尘器？

更新

这可能是一个锁定问题吗？有问题的表是通过插入后触发器填充的汇总表。这些表以 SHARE ROW EXCLUSIVE 模式锁定，以防止并发写入同一行。

我在 Ubuntu 上使用 PostgreSQL 9.1。VACUUM ANALYZE仍然推荐预定，还是 autovacuum 足以满足所有需求？

如果答案是“视情况而定”，那么：

• 我有一个较大的数据库（30 GiB 压缩转储大小，200 GiB 数据目录）
• 我对数据库做 ETL，每周导入接近 300 万行
• 变化最频繁的表全部继承自一个主表，主表中没有数据（数据按周分区）
• 我创建每小时汇总，并从那里创建每日、每周和每月报告

我问是因为预定的时间VACUUM ANALYZE会影响我的报告。它运行了 5 个多小时，本周我不得不杀死它两次，因为它影响了常规的数据库导入。check_postgres不会报告数据库有任何显着膨胀，所以这不是真正的问题。

从文档中，autovacuum 也应该处理事务 ID 环绕。问题是：我还需要一个VACUUM ANALYZE吗？

我使用的软件，这使得一个很大的PostgreSQL数据库（有一个表中有一个百万行）和开发商说我应该VACUUM和ANALYZE周期性。但是 PostgreSQL 数据库默认是autovacuum开启的。

我应该抽真空/分析吗？有什么好处？自动抽真空和手动抽真空有什么区别

例如，在 Pgadmin3 中，我有这个：