问题标签 [autovacuum]

我有 postgresql RDS 和 Aurora 实例。在版本 12 上，有一个接近 200M trx id 的热表。为了防止它在 trx 环绕时遇到 autovacuum，我将表 autovacuum_freeze_max_age 设置为 600M，因为我无法执行重新启动以在实例级别更改此值 autovacuum_freeze_max_age。

alter table sample_table SET (autovacuum_freeze_max_age=6000000000);

但是，当表达到 trx id 200M 时，会触发该表的 autovacuum trx 环绕。即使我检查了表结构，上面的 autovacuum_freeze_max_age 值也更新为 600M。

现在的问题是

1. 为什么即使有这些变化也会发生这种情况？
2. 需要检查任何其他参数吗？

任何建议表示赞赏。提前致谢。

我们一直在尝试调整一些较大表上的 autovacuum 阈值，否则它们永远不会运行，而且还会建立成千上万的死元组。使用我在 SO 上某处找到的查询，查看pg_stat_user_tables表格，我可以看到上次运行时间和 autovacuum 的运行次数，但我似乎无法找到事件的历史记录。我们正在尝试跟踪他们运行的频率，以了解一个好的阈值在哪里，这样这类信息就会很有用。是否有另一张桌子可用于此？

我试图弄清楚为什么没有对超过 100 万行的表执行任何分析工作。如果我运行以下查询：

我明白了1,668,422

但是，当我检索同一张表上的统计信息时：

我们可以看到没有进行任何分析。然后我的期望n_tup_ins是等于或大于第一个查询的行数（并且n_live_tup相等）。也n_tup_ins - n_dead_tup应该等于n_live_tup

我有以下设置值：

因此，即使使用统计数据中的元组计数，如果我们应用公式autovacuum_analyze_scale_factor * number of tuples + autovacuum_analyze_threshold，我们应该得到0.1 * 140514 + 50 = 14101.4, 小于n_tup_ins = 140514，因此应该触发分析作业，对吗？

我在这里想念什么？

我又带着另一个 Postgres 问题来了。我们正在使用 Azure 的托管服务，该服务使用autovacuum. 两者都是自动的vacuum。statistics

我遇到的问题是，对于特定查询，当它在特定时间运行时，计划不好。我意识到，在手动收集统计数据后，该计划再次表现得更好。

从 Azure 的文档中，我得到了以下信息：

真空进程读取物理页面并检查死元组。shared_buffers 中的每个页面都被认为具有 1 的成本 (vacuum_cost_page_hit)。如果存在死元组，则所有其他页面的成本为 20 (vacuum_cost_page_dirty)，如果不存在死元组，则认为成本为 10 (vacuum_cost_page_miss)。当进程超过 autovacuum_vacuum_cost_limit 时，vacuum 操作停止。

达到限制后，进程在再次启动之前休眠 autovacuum_vacuum_cost_delay 参数指定的持续时间。如果未达到限制，则 autovacuum 在 autovacuum_naptime 参数指定的值之后启动。

总之，autovacuum_vacuum_cost_delay 和 autovacuum_vacuum_cost_limit 参数控制每单位时间允许多少数据清理。请注意，对于大多数定价层来说，默认值太低。这些参数的最佳值取决于定价层，应进行相应配置。

autovacuum_max_workers 参数确定可以同时运行的最大 autovacuum 进程数。

使用 PostgreSQL，您可以在表级别或实例级别设置这些参数。现在，只能在 Azure Database for PostgreSQL 中的表级别设置这些参数。

假设我想强调特定表的默认值，因为目前所有表都使用整个数据库的默认值。

请记住，我可以尝试使用（X我不知道在哪里）

目前我有这些值pg_stat_all_tables

到目前为止，这两个表是获得大部分 DML 活动的表。

问题

• 如何确定 auto_vacuum 的这些特定参数的哪些值最适合具有大量 dml 活动的表？
• 如何强制 Postgres 对这些表运行更多次自动分析，以便获得更多最新统计信息？根据文档

autovacuum_analyze_threshold

指定在任何一个表中触发 ANALYZE 所需的最小插入、更新或删除元组数。默认值为 50 个元组。该参数只能在 postgresql.conf 文件或服务器命令行中设置；但是可以通过更改表存储参数来覆盖单个表的设置。

• 这是否意味着删除、更新或插入达到 50 次会触发自动分析？因为我没有看到这种行为。

• 如果我更改表的值，我应该对它们的索引做同样的事情吗？有没有像级联或类似的选项改变表使值也会影响相应的索引？

提前感谢您的任何建议。如果您需要更多详细信息，请告诉我。

我们使用 PostgreSQL 进行分析。我们对表执行的三个典型操作是：

• 创建表作为选择
• 创建表，然后在表中插入
• 删除表

我们没有做任何事情UPDATE，DELETE等等。

对于这种情况，我们可以假设估计是准确的吗？

我正在使用 CloudSQL - GCP 的 postgresql12 版本。

我们目前正在输入数十亿的数据，我们不希望输入在中间被中断。

但是，我在 CloudSQL 标志中将 autovacuum 设置设置为关闭，但它似乎每天都会自动完成。

随着 autovacuum 的进行，使用 python sqlalchemy 的输入会导致错误。

解决办法是什么？

我在 GCP 上将 postgresql 用于 cloudSQL。

一张表几乎处于插入过程中。（理论上每天超过1000万）

数据大约为 100 亿时，进行了自动抽真空。

此外，当自动清理运行时，其他进程只能由单个用户使用。

也许是真空冷冻的效果。

确切的原因是什么？

并且我决定如果自动真空运行的次数较少且频繁，则执行周期会更短，因此我将参数修改如下。

是否有任何参数需要修改以进一步提高性能？

我们在我们的应用程序中使用 Postgresql 9.4，并且某些表的死元组没有被正确删除。我们使用默认配置开启了 autovacuum。以下是一些日志（这会持续一整天）：

如您所见，vacuum 至少需要 200 秒并且没有删除任何元组。这也发生在其他表上。已经检查常见原因：

• 长时间运行的事务
• 未提交的准备好的事务。
• 过时的复制槽。

但这些都不适用于我们的案例

在我们的一张大表（~100Gb）上触发 autovacuum 时，我们遇到了一些问题。

我们的 ETL 作业只命中了该表的最后三个分区，但据我了解，当在一个分区上触发 autovacuum 时，整个表都会被清空，这会导致 ETL 作业一直等到它完成。

到目前为止，我已经尝试将 autovacuum_vacuum_scale_factor 设置为更高和更低的值，从而为我们的工作产生大致相同的执行时间。

由于在此表上执行了相当重要的 INSERT/UPDATE 次数，我想在三个 last 分区上设置一个较低的 autovacuum_vacuum_scale_factor 值，但要防止对旧分区进行清理。

我们已经在使用每天晚上运行的真空脚本，所以我正在考虑在旧分区上将 autovacuum_enabled 设置为关闭，并让脚本处理这些表上的真空，但我不确定这是否是处理这个问题的正确方法.

我偶然发现的另一个参数是vacuum_freeze_min_age 和autovacuum_freeze_max_age，但我不确定我是否了解如何使用它们。