为什么会运行autovacuum: VACUUM ANALYZE（以防止wraparound）？

Question

我有一个自动清理工具VACUUM ANALYZE任务运行在一张表上，它总是需要几个小时甚至几天才能完成。我知道Postgres会偶尔运行自动清理和维护任务，这是必要的。然而，大多数表只需进行清理，不需要进行分析。

为什么这个特定的表需要进行清理和分析？如何解决它花费太长时间的问题？

另外，我之前并没有注意到运行这个清理和分析任务。直到几天前我尝试创建索引时，操作失败了，显示已经耗尽打开的文件（或类似的错误）。这可能导致清理和分析任务运行时间过长吗？

- Henley

---

“VACUUM ANALYZE” 而不是 “VACUUM FREEZE”？你的PostgreSQL版本是多少？日志中有任何有用的信息吗？你在主题中提到了事务ID环绕 - 你从哪里得到的这个信息？ - Craig Ringer

是的，请分析而不要冻结。我正在使用Postgres 9.2。我从pg_stat_activity中获取查询pid、query、query_start，其中查询类似于'%auto%'。 - Henley

好的... PostgreSQL日志中有什么有趣的内容吗？为什么要提到“防止环绕” - 这是从哪里来的？ - Craig Ringer

pg_stat_activity.query 可以显示类似这样的语句： autovacuum: VACUUM myschema.my_table (为了防止环绕)。 在我的情况下，它目前正在阻止升级到9.5后的VACUUM ANALYZE。 - Robert Casey

Answer 1

从PG 9.1升级到PG 9.5时，一些表的XID冻结限制达到了。结果是，正在运行的系统在许多表上运行自动清理过程，其中许多表都显示“(为了防止环绕)”。到目前为止，这是一个非常繁忙的数据库，所以我并不感到惊讶。

由于我无法强制自动清理不执行此操作，并且这样做是一个坏主意，因此我重新配置了否则闲置的数据库，以高速运行自动清理，以便它能够更快地完成（希望如此），我们可以回到业务中。

我在我的postgres.conf中暂时设置了以下内容，它似乎工作得非常好。确实让I/O运转起来。我省略了其他优化WAL大小和事务的附加设置，因为那高度依赖于系统：

# TEMPORARY -- aggressive autovacuum
autovacuum_max_workers = 16           # max number of autovacuum subprocesses
autovacuum_vacuum_cost_delay = 4ms    # default vacuum cost delay for
                                      #     autovacuum, in milliseconds;
autovacuum_vacuum_cost_limit = 10000  # default vacuum cost limit for autovacuum

我会停止和启动数据库服务器，然后使用类似以下的shell调用来监控正在发生的事务：

watch -d -n 300 psql -c "select query from pg_stat_activity;"

- Robert Casey

Answer 2

我认为VACUUM ANALYZE只是一个误导。这张表同时需要VACUUM和ANALYZE，所以它正在执行VACUUM ANALYZE，但我真的怀疑ANALYZE是否有任何贡献问题。

我想知道"VACUUM（以防止环绕）"是否会完成，或者中途被打断并因此重新启动而没有真正取得进展。检查一下日志文件可以帮助澄清这个问题（以及帮助澄清关于运行文件不足的事情）。

此外，根据表格的大小和您的代价基础上的吸尘设置，您应该能够估计出吸尘所需的时间，并比较实际花费的时间。

另外，您系统上的交易吞吐量与环绕问题非常相关。除非您的数据库异常活跃，否则环绕吸尘应该非常罕见。

- jjanes