Postgres自动清理不回收死元组空间导致磁盘已满

问题描述

我有一个用例，它在另一端每分钟同时插入10万行，几个线程将占用这些行并将其从我的表中删除。因此，肯定会在我的表中创建很多死元组。

我的自动真空配置是

autovacuum_max_workers = 3
autovacuum_naptime = 1min
utovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.1
autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit = -1

从“ pg_stat_user_tables”中，我可以发现表上正在运行自动真空，但几个小时后我的磁盘将已满（500 GB），并且我无法插入任何新行。

第二次尝试，我更改了以下配置

autovacuum_naptime = 60min
autovacuum_vacuum_cost_delay = 0

这次，我的模拟和自动真空运行良好，最大磁盘大小为180 GB。

我的疑问是，如果我将“ autovacuum_vacuum_cost_delay”更改为零毫秒，那么如何自动真空释放死元组空间并PG重用它？如果将值设置为20 ms，为什么它不能按预期工作？

解决方法

我的疑问是，如果我将“ autovacuum_vacuum_cost_delay”更改为零毫秒，那么如何自动真空释放死元组空间并PG重复使用它？

由真空释放的空间记录在free space map中，从那里分发出去，以供将来的INSERT重新使用。

要添加的另一个详细信息，在9.6中，仅在整个表本身完全被清理后才清理空闲空间图，因此直到那时才找不到释放的空间。如果VACUUM从未达到极限，因为它太慢或被中断，那么它释放的空间将不会被INSERT重用。在v11中对此进行了改进。

如果将值设置为20 ms，为什么它不能按预期工作？

因为真空度无法保持在该值。 PostgreSQL的默认值通常仅适用于较小的服务器，而您似乎并不适合。在这种情况下，更改默认值是适当且可取的。请注意，在v12中，默认值从20降低到了2（其类型也相应地从int更改为float，因此您现在可以更精确地指定值）

,

总而言之，您的应用程序会创建大量死元组，并且自动清理无法跟上。可能的解决方案

1. 这听起来像是任务队列，而不是常规表。 PostgreSQL表可能不适合您这种特定的用例。请改用RabbitMQ / Redis之类的解决方案。
2. 创建基于时间的范围分区，并在旧分区为空时清除旧分区，同时仅在此表上禁用自动清理。如果可以识别已处理的分区，请考虑完全不删除行，而只是清除旧分区。
3. 调整自动真空设置，以使其持续工作，而不会出现小睡或干扰。增加maintenance_work_mem也可以帮助提高自动真空度。也许您会发现自己已经达到硬盘极限。在这种情况下，您将不得不优化存储，以使其能够容纳那些昂贵的INSERT + DELETE + autovacuum操作。

,

那么默认值为2 ms Autovacuum。因此，您的20ms值很高：

autovacuum_vacuum_cost_delay（浮点数）

“指定将在自动VACUUM操作中使用的成本延迟值。如果指定-1，则将使用常规vacuum_cost_delay值。如果指定此值而无单位，则以毫秒为单位。默认值为2毫秒。只能在postgresql.conf文件或服务器命令行中设置此参数；但是可以通过更改表存储参数来覆盖单个表的设置。”

如此处Vacuum所述：

” vacuum_cost_delay（浮点数）

超过成本限制时，进程将进入休眠状态的时间。如果指定的该值不带单位，则以毫秒为单位。默认值为零，这将禁用基于成本的真空延迟功能。正值可实现基于成本的清理。

在使用基于成本的吸尘时，vacuum_cost_delay的适当值通常很小，可能小于1毫秒。尽管vacuum_cost_delay可以设置为分数毫秒值，但是在较旧的平台上可能无法准确测量此类延迟。在此类平台上，将VACUUM的节流资源消耗增加到1ms以上，将需要更改其他真空成本参数。但是，您应该将vacuum_cost_delay保持为平台将持续测量的大小；大的延误没有帮助。 “