PostgreSQL 8.3 - 自动清理问题

Question

我在 StackOverflow 上发布了这个，有人建议这个查询更适合这里。

我试图鼓励在某些 PostgreSQL 8.3 数据库中使用和监控 autovacuum。

我经常遇到的一个反对意见是人们不“信任” autovacuum 或者 8.3 中的 autovacuum 中存在错误，这意味着它优先于调度清理而被忽略。大多数情况下，我们的表都很小，这种方法似乎有效。但是，对于我们更大的（以及大量更新的表），这确实不起作用（死元组计数增加，超过 max_fsm_pages，并且表没有被清理等）。

我只是想知道是否有人对 8.3 中的 autovacuum 有问题或不工作有参考。我自己的经验表明 autovac 工作正常，并且在必要时向 pg_autovacuum 表添加条目可以解决问题。

我想了解 autovacuum 的问题（如果存在）。

Answer 1

• 我找不到任何证据表明 8.3 autovacuum 有问题。Autovacuum 在 8.4 中得到了改进，具有自由空间映射，它废弃了一些参数：

  （设置不正确时）可能会降低真空效果

  所以在 8.3 中正确设置它们很重要。

• postgres wiki说（我倾向于同意）：

  从 8.3 开始，默认情况下自动清理是打开的，您应该保持这种状态。

  和：

  几乎所有吸尘问题的答案是更频繁地吸尘，而不是更少，这样每个单独的吸尘操作就可以减少清理。

• 正如您所说，当需要调整 autovacuum 时，“向 pg_autovacuum 添加条目可以解决问题” - 但请注意“pg_autovacuum [is] 未保存在数据库转储中”

Answer 2

我运行着一些非常繁忙的 8.3 db 服务器。当我第一次开始研究它们时，他们每半周就搞砸他们的自由空间地图设置并偏离轨道。解决方案是提高 fsm 设置，并使 autovacuum 更具侵略性。

autovacuum_vacuum_cost_delay 下降到 0 或 1ms autovacuum_vacuum_cost_limit 上升到 5000 max_fsm_pages 上升到 2M 到 10M，具体取决于机器 max_fsm_relations 上升到 10k 到 100k，具体取决于机器 autovacuum_max5 取决于机器

这些机器都有相当强大的 IO 子系统（8 到 32 个 15K SAS 驱动器，带有各种硬件 RAID 卡或 SAN）。

简而言之，如果有人认为 8.3 中的 autovac 有问题并且不会使用它，那么他们可能并没有真正理解它，并且基于迷信而非科学以特定方式行事。