问题标签 [autovacuum]

我有几个关于 autovacuum 的问题：

1. 在加载/更新数据或大查询的漫长过程之前关闭清理是否安全？

2. autovacuum 的推荐配置是什么？

我想利用 Postgres 中仅索引扫描的强大功能并尝试使用一个表：

该索引涵盖了我想在下一个查询中使用的所有列：

我在创建后立即检查计划：

这很奇怪，但好吧......

在几秒钟内它变成另一个（自动真空？）

我尝试强制它使用仅索引扫描：

但这并没有改变任何东西。然后我做

在这里，我终于得到了我想要的：

所以这里有问题：

1. 为什么不analyze教它使用大的“全覆盖”索引？
2. 为什么这样vacuum analyze做？
3. 我的桌子从头开始装满了一个大的插入物。为什么vacuum什么都做？在我看来，那里没有什么可以吸尘的。

具有 READ COMMITTED 隔离级别，已执行写操作的空闲事务将防止清理事务写入的表的死行。

对于由仍在进行中的事务写入的表来说，这一点很清楚。在这里你可以找到一个很好的解释。

但我不清楚为什么这个限制也会影响任何其他表。

例如：事务 T 启动并更新表 B，当 T 处于“事务中的空闲”状态时，对表 A 执行真空。在这种情况下，为什么无法删除 A 中的死行？

这是我所做的：

此时我进行更新以生成新的 1000 死行

吸尘将按预期删除它们：

我现在开始在表 b 中写入事务 T：

我在 T 之后开始的不同事务 T1 中再次生成更多死行：

在不同的交易中：

这是相关部分：细节：1000 个死行版本还不能被删除。

如果我提交事务 T 并再次执行真空，我会按预期删除死行：

我对postgresql没有那么有经验。

做了一个简单的命令

涉及数千行。但是实际上在该命令之后，磁盘空间变得更小了。

任何想法出了什么问题？我启用了 autovacuum = on 并尝试执行 'VACUUM FULL;' 但这消耗了我的整个磁盘空间。

我想做的很简单。删除行并获取空间。涉及的空间很大，机器上没有那么多空间。有没有办法做到这一点？

我有一个非常更新的重表。问题是表增长了很多，因为 autovacuum 无法赶上。autovacuum 每 2 分钟启动一次，因此它正在运行文件。

我有一个应用程序每 60-70 秒进行 50k 更新（和一些插入）。

我被迫每周做 CLUSTER，这不是 IMO 的最佳解决方案。我的 autovacuum 设置如下（加上相关）：

这是自动清理日志：

2018-01-02 12:47:40.212 UTC [2289] 日志：表“mydb.public.sla”的自动真空：索引扫描：1 页：0 已删除，21853 保留，1 由于引脚而跳过，0 跳过冻结元组：已删除 28592，保留 884848，38501 已死但尚未可移动缓冲区使用：240395 次命中，15086 次未命中，22314 脏平均读取速率：29.918 MB/s，平均写入速率：44.252 MB/s 系统使用率：CPU 0.47s/2.60 u 秒经过 3.93 秒

在我看来，29 MB/s 太低了，考虑到我的硬件还不错

我有英特尔 NVMe 设备，我的 I/O 似乎没有饱和。

Postgresql 版本：9.6
CPU：双 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz

任何想法如何改善这一点？

我正在使用 PostgreSQL 9.6（Ubuntu 16.04），我有一个大约 10k 行的小表 T，其中每行在高峰时间每分钟更新 2 次（类似于UPDATE T SET c1 = ?, c2 = ? WHERE id = ?）。此外，这是在此表中完成的唯一更新操作，并且插入和删除根本不经常。

但是，我注意到SELECTT 中的查询有点慢，经过一番研究，我发现“PostgreSQL 中的更新实际上是 DELETE+INSERT (due MVCC) 的事务”。此外，我发现了类似的问题this one和this one，但与UPDATE查询有关。

我的问题是：连续频繁更新会减慢选择查询的速度吗？如果是这样，处理它的正确方法是什么？

来自 PostgreSQL（相对）新手的快速问题：

我们运行一个批处理，作为其最后一步，删除大部分以前的批处理。

磁盘空间是一个问题，因此我们需要确保 PostgreSQL 自行清理。

除了强制 PostgreSQL 更快地进行垃圾收集之外，在批处理结束时显式调用 VACUUM 与让 auto-VACUUM 守护进程处理它之间有什么区别吗？有什么理由推荐一种方法而不是另一种方法吗？

谢谢！

运行 postgres 9.6，大数据表大量事务发生在表上。在每 100,000 次更改（左右）之后，VACUUM FREEZE针对该表运行一次。我的理解是，这将与自动吸尘器相同，AUTO_VACUUM (to prevent wrap-around)但仍会自动吸尘。所以我的问题是我如何手动启动这个VACUUM过程来做同样的事情AUTO_VACUUM？

我认为既然您可以完全关闭自动真空吸尘器，那么必须有一种手动执行此操作的方法。

为了进一步澄清，我在日志中收到了这些错误：

Postgresql 具有 Vacuum 的功能，用于回收死元组占用的空间。自动吸尘默认开启并根据配置设置运行。

当我检查 pg_stat_all_tables 的输出，即 last_vacuum 和 last_autovacuum 时，从未对数据库中具有足够数量的死元组（超过 1K）的大多数表运行 autovacuum。当这些表很少使用时，我们还会获得 2-3 小时的时间窗口。

以下是我的数据库的 autovacuum 设置

下面是 pg_stat_all_tables 的输出

我想问一下，只依靠自动吸尘器是个好主意吗？autovacuum 是否需要任何特殊设置才能正常运行？
我们应该设置手动吸尘器吗？我们应该同时使用两者还是只关闭自动吸尘器并仅使用手动吸尘器？

尽管启用了自动清理功能，但很少有表和索引臃肿。

两个回收空间真空，我在较大的表上运行了完全真空，并且还对较大的索引执行了重新索引。现在数据库的大小是可控的。

在对较大的表执行完全真空并重新索引后，我面临以下错误。

org.postgresql.util.PSQLException：错误无法打开文件“base/16384/19048”：没有这样的文件或目录

请指导我如何解决上述错误，并让我知道这与我执行的 vacumm full 或 reindexing 操作是否有任何关系。