问题标签 [autovacuum]

我需要删除大约 80% 的 500Gb Postgresql 数据库。到目前为止，我已经成功地为大约 50Gb 的行运行了删除命令，并在继续之前暂停了。（这花了很长时间，也许一个小时）

我注意到在删除大约 50Gb 的数据后，没有释放额外的磁盘空间，但是当我运行“htop”时可以观察到一些内存密集型 postgres 进程。假设这归结为死行，我是否正确，需要在释放磁盘空间之前对其进行清理？

这个问题的第二部分是，如果我没有弄错第一部分，我最好删除所有行然后允许自动真空发生吗？在我有机会继续我的行删除命令列表之前，似乎自动真空（或其他一些密集的后台进程）已经自行启动。我应该继续还是应该优雅地告诉它先停止？

全部，

请在此处建议，自动真空/真空不会释放 postgreSQL 9.6 版本中表的死行，任何人都可以帮助这里需要检查的内容，或者是否有任何参数调整来删除死行。

问候， 瓦伦

如果参数autovacuum是on，并且参数track_counts也是on- 为什么看起来 autovacuum 从来没有工作过？

没有行...

使其运行需要哪些操作？

我的版本是：PostgreSQL 9.6

试图让 Postgresql 保持表更清洁，但是即使在调整资源限制之后，它似乎也几乎没有跟上。

即使设置后

veryactivetable 的 pg_stat_user_tables 返回 63356 n_dead_tup 并且 last_autoanalyze 和 last_autovacuum 超过 24 小时

posgresql.conf 设置：

我的架构中有一张表没有被自动清空。如果我VACUUM posts;在桌子上运行，真空过程会很好地完成，但 autovacuum 守护进程不会出于某种原因对桌子进行真空吸尘。有没有办法找出原因？这可能是什么原因？

我们在 Centos 操作系统上使用 postgres 9.2 版本。我们有大约 1300 多张桌子。我们启用了以下自动真空设置。仍然很少有总是很忙的表（84 个表）没有被清理。这些表中的死元组超过 5000 个。由于这些表正在膨胀，并且观察到的区域很少有性能下降。

为了避免表膨胀和性能下降，我们想为繁忙的表设置'autovacuum_vacuum_scale_factor'（零）和'autovacuum_vacuum_threshold'（200）设置，如下所示。如果我将某些表的 autovacuum 比例因子设置为零，请告诉我是否对 DB 有任何不利影响。如果是，效果如何，如何测试。

请让我知道 autovacuum_vacuum_cost_delay 和 autovacuum_vacuum_cost_limit 设置的作用。

“autovacuum_naptime”和“autovacuum_vacuum_cost_delay”有什么区别？

“autovacuum 启动器进程”和“autovacuum 工作进程”有什么区别？

如何控制“autovacuum launcher process”和“autovacuum worker process”的数量？

“autovacuum 启动器进程”是否休眠？如果是，哪个参数控制它？

“autovacuum worker 进程”是否休眠？如果是，哪个参数控制它？

如何在Linux机器中监控这些参数相关进程？

我有一个非常大的表，400MM 记录，通常只接收插入。但是，最近我必须对记录进行大量更新才能完成任务。这会创建很多死元组。我已将全局配置更新为以下内容：

有了这些设置，我的意图是，每当死元组超过 10,000 条记录时，自动清理就会清理它。

但是，我发现当表忙于其他插入等时，死元组计数不会改变。它保持固定在某个死元组计数。只有当 db 活动在夜间减慢时，autovacuum 才能正常工作。

我需要 autovacuum 全天积极处理死元组。我将如何做到这一点？我需要增加 max_workers 数量吗？

更新：用户@Laurenz Albe 建议我运行一些带有和不带有死元组的性能数字来展示性能差异。

我将提供 sql 查询和 EXPLAIN(ANALYZE, BUFFERS) 结果。我更改了表的名称和组键以保护隐私。

-- >>> 大约 1%（383.2MM 中的 3.648MM）死元组，结果如下。

-- >>> 有 0 个死元组，结果如下。

我有一个无法安全终止的进程正在运行： autovacuum: VACUUM public.mytable （以防止环绕）

该表已被清除（除了一些由于硬件问题导致表损坏而无法删除的条目）并且不能被删除，因为真空正在阻止它。我不得不运行 kill -9 来停止这个过程并重新启动数据库，但是你不能禁用这个自动清理（以防止 [事务] 环绕），所以自动清理会重新启动并立即被这个损坏的表卡住。

对此有任何见解吗？

在 PostgreSQL 9.5 中，我决定创建一个物化视图“效果”并安排每小时一次的并发刷新，因为我希望它始终可用：

一开始一切都很好，我的物化视图令人耳目一新，磁盘空间使用量或多或少保持不变。

问题

一段时间后，磁盘使用量开始线性增长。

我得出的结论是，这种增长的原因是物化视图，并从此答案运行查询以获得以下结果：

然后，我发现上次自动清空该表是在两天前，通过运行：

我决定手动调用vacuum (VERBOSE) effects. 它运行了大约半个小时，并产生了以下输出：

在这一点上，我认为问题已经解决，并开始考虑可能会干扰自动吸尘器的原因。可以肯定的是，我再次运行查询以查找该表的空间使用情况，令我惊讶的是它并没有改变。

只是在我打电话后REFRESH MATERIALIZED VIEW effects; 不并发。只是现在检查表大小的查询的输出是：

而一切又恢复了正常……

问题

问题已解决，但仍有相当多的混乱

1. 谁能解释我遇到的问题是什么？
2. 以后如何避免这种情况？