问题标签 [autovacuum]

AWS 中的 PostgreSQL 9.5.2 RDS

我一直试图弄清楚自动吸尘如何在两个 Postgres 数据库中工作。数据库的大小、参数和结构相同。（这是同一个应用程序的两个数据仓库——不同的位置和不同的数据模式）。

我们正在为一些非常大的表使用分区。我注意到较旧的（静态）分区会定期自动清空。我知道 XID 已被冻结，但该关系确实需要定期清理以查找新的 XID。

我一直在使用此查询来查找需要清理以避免 XID 环绕的关系：

列出的所有关系都是旧的稳定分区。列 relfrozenxid 定义为：“在此之前的所有事务 ID 都已替换为此表中的永久（“冻结”）事务 ID。这用于跟踪是否需要对表进行清理以防止事务 ID 回绕或允许 pg_clog 缩小。”

出于好奇，我查看了特定表的所有分区的 relfrozenxid：

我很确定我并不真正了解 relfrozenxid 的工作原理，但似乎分区表受到父表的影响（这会影响分区表的 relfrozenxid 值）。我找不到任何有关此的文档。我认为对于静态表，relfrozenxid 将保持静态，直到出现真空。

此外，我有一些具有静态数据的关系，这些数据显然从未被自动清理过（last_autovacuum 为空）。这可能是 VACUUM FREEZE 操作的结果吗？

我是 Postgres 的新手，我很乐意承认自己没有完全理解自动真空过程。

我没有看到我可以识别的性能问题。

编辑：

我设置了一个查询，每 4 小时针对一个分区表运行一次：

在这里查看两个不同的分区是过去 20 小时的输出：

即使分区没有直接的 DML，分区的 relfrozenxid 也会被修改。我会假设对基表的插入以某种方式修改了分区的 relfrozenxid。

分区 sometable_201610 有 3100 万行，但是是静态的。当我查看日志文件时，这种分区的 autvacuum 需要 20-30 分钟。我不知道这是否是性能问题，但它看起来确实很昂贵。查看日志文件中的 autovacuum 表明，通常每晚都会自动清理多个此类大型分区。（也有很多零元组的分区是自动清空的，但这些分区只需要很少的时间）。

我有两张桌子：Table1和Table2。
如果有长时间运行的查询：
Select * from Table2;
它会影响 AutoVacuum 进程Table1吗？

在 Postgres DB (9.4) 中，我们有一个包含 3500 万行的表。数据是快速静态的，首先用 COPY 插入，然后计算几个字段。

计算的一个例子是：

the_partition 可能有 5 个不同的值，因此不会对整个表进行计算，但需要 5 个请求来更新 the_name。

更新 500 000 => 大约需要 30 秒 当 5 000 000 => 应该需要 300 秒，即 5 分钟

但是对于 15 000 000，它在几个小时后并没有完成......

我怀疑自动吸尘器没有做好它的工作，所以我尝试将它设置得更积极，预计它应该在 500 000 行更新后自动吸尘

但据我了解，当我运行 15 000 000 的大更新时，它在同一个事务中，因此不会应用自动真空广告广告 15 000 000 的新闻行将被存储，直到请求完成（如postgresql 复制更新的行）？那么如何使计算时间成为线性的呢？

我有一个每分钟有 80K 写入的表。我做了一个改变来减少这个表的负载（现在它是每分钟 40K 写入）。

目前我可以看到有一个已经运行了 3 天以上的 autovacuum（！）和我的表（autovacuum: VACUUM ANALYZE table（以防止环绕）

我应该手动运行“真空表”吗？只要我不停止写入，它就会结束吗？

我应该终止这个“autovacuum”过程吗？

任何建议将不胜感激！

我有一个 Postgres 9.6 RDS 实例，它每天增长 1GB。我们对与 pg_toast 相关的关系进行了一些优化，但 pg_toast 的大小没有改变。

Autovacuum 已开启，但由于 autovacuum/VACUUM FREEZE 不会回收空间，而 VACUUM FULL 会执行独占锁定，因此我不再确定最好的方法是什么。

表中的数据是我们用户体验的核心，尽管遵循这种方法是有意义的，但它会带走我们的用户期望在真空完整过程中看到的数据。

这里还有哪些其他选项可以缩小 pg_toast？

以下是有关表格大小的一些数据。您可以在前两张图片中看到，关系scoring_responsescore是与 pg_toast 关联的关系。

自动真空设置

该特定 pg_toast 当前正在运行的 autovacuum 进程的结果。它可能会有所帮助。

我已将我的 sqlite 数据库的 auto_vacuum PRAGMA 的值更改为 INCREMENTAL。当我PRAGMA incremental_vacuum;通过“DB Browser for SQlite”应用程序运行时，它会释放free_list. 但是，当我使用 C# 中的任何 SQLite 库（例如Microsoft.Data.SQLite）运行相同的语句时，它只会从free_list

我通过在运行语句之前和之后运行来获取当前的数字来验证free_list这一点PRAGMA freelist_count。PRAGMA incremental_vacuum

此外，我尝试将不同的参数传递给incremental_vacuumpragma，例如PRAGMA incremental_vacuum(100)，但它仍然只会释放一页。

如果我在这里做错了什么，请告诉我。

提前致谢！

我正在尝试在 PostgreSQL 11 上调整分区表上的 autovacuum 设置。

例如：

是否可以更改分区表上的此类设置？

我们的 Postgres DB（托管在具有 1 个 CPU、3.7 GB RAM 的 Google Cloud SQL 上，见下文）主要由一个约 90 GB 的大表组成，其中约 6000 万行。使用模式几乎完全由附加和表末尾附近的一些索引读取组成。有时会删除一些用户，删除分散在表中的一小部分行。

这一切都很好，但每隔几个月就会在该表上触发一次自动清理，这会显着影响我们服务的性能约 8 小时：

• 在 autovacuum 期间（几个小时），存储使用量增加了约 1GB，然后慢慢恢复到之前的值（由于 autovacuum 释放页面，最终可能会下降到该值以下）
• 数据库 CPU 利用率从 <10% 跃升至 ~20%
• 磁盘读/写操作从接近零增加到 ~50/秒
• 数据库内存略有增加，但保持在 2GB 以下
• 正如预期的那样，事务/秒和入口/出口字节也几乎不受影响

这会在 autovacuum 期间将我们服务的第 95 个延迟百分位从 ~100ms 增加到 ~0.5-1s，这反过来又会触发我们的监控。该服务每秒处理大约 10 个请求，每个请求由几个简单的 DB 读/写组成，每个请求通常有 2-3 毫秒的延迟。

以下是一些说明该问题的监控屏幕截图：

数据库配置相当普通：

记录此 autovacuum 过程的日志条目如下所示：

有什么建议我们可以调整以减少未来自动吸尘器对我们服务的影响吗？还是我们做错了什么？

我们正在为我们的生产评估 PostgreSQL 11.1。拥有一个每秒更新 4251 次、每秒删除约 1000 次、每秒插入约 3221 次、每天处理 10 亿次事务的系统，我们面临的挑战是 PostgreSQL 不重用其（删除/更新）空间，并且表的大小不断增加.

我们配置了激进的 Autovacuum 设置以避免环绕情况。还尝试添加定期执行vacuum analyze和vacuum- 仍然没有空间重用。（仅vacuum full或pg_repack向操作系统释放空间——但这不是重用。）

以下是我们的真空设置：

PG日志越来越多

2019-03-08 07:01:20 PST LOG：自动清理表“hpdpidb.hpdpidb_app.dp_catalog_object_versession”：无法（重新）获取截断扫描的排他锁

谁能告诉我这个日志消息？为什么我会得到这个？我需要担心这个吗？如何忽略/解决这个问题？