为什么自动真空:真空分析(以防止缠绕)运行？

Question

我有一个在表上运行的自动真空真空分析查询，它总是要花费很多小时，甚至几天的时间才能完成。我知道Postgres偶尔会运行自动真空作业来执行清理和维护任务，这是必要的。然而，大多数表只是一个真空，而不是真空分析。

为什么这个特定的表格需要真空分析，我怎样才能解决它花了这么长的时间？

另外，我没有注意到几天前运行的真空分析查询。这就是我试图创建索引的时候，它过早地失败了，说它没有打开的文件(或者类似的文件)。这会不会有助于真空分析运行这么长时间？

Answer 1

我认为真空分析是一种红鲱鱼。这个表是同时进行真空分析和分析的，所以它是在做真空分析，但我真的怀疑分析是否会导致这个问题。

我想知道“真空(防止缠绕)”是否正在结束，或者它是否被中断了一部分，因此重新开始，而没有取得真正的进展。对您的日志文件进行良好的检查应该有助于澄清这一点(以及帮助明确打开的文件耗尽的确切原因)。

此外，根据表的大小和基于成本的吸尘设置，您应该能够估计真空需要多长时间，并比较实际需要多长时间。

此外，您的系统上的事务吞吐量与环绕问题非常相关。除非您的数据库异常活跃，否则环绕真空应该非常罕见。

Answer 2

从第9.1页升级到第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

我停止并启动db服务器，然后使用shell调用监视发生的事务，如下所示：

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