如何解决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,因此您现在可以更精确地指定值)
,总而言之,您的应用程序会创建大量死元组,并且自动清理无法跟上。可能的解决方案
- 这听起来像是任务队列,而不是常规表。 PostgreSQL表可能不适合您这种特定的用例。请改用RabbitMQ / Redis之类的解决方案。
- 创建基于时间的范围分区,并在旧分区为空时清除旧分区,同时仅在此表上禁用自动清理。如果可以识别已处理的分区,请考虑完全不删除行,而只是清除旧分区。
- 调整自动真空设置,以使其持续工作,而不会出现小睡或干扰。增加
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保持为平台将持续测量的大小;大的延误没有帮助。 “
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。