Questions tagged «vacuum»

我试图让PostgreSQL主动自动清理数据库。我目前已将自动吸尘配置如下： autovacuum_vacuum_cost_delay = 0＃关闭基于成本的真空 autovacuum_vacuum_cost_limit = 10000＃最大值 autovacuum_vacuum_threshold = 50＃默认值 autovacuum_vacuum_scale_factor = 0.2＃默认值 我注意到只有在数据库未处于负载状态时才会启动自动清理功能，因此我遇到了这样的情况：死元组比活动元组多得多。有关示例，请参见随附的屏幕截图。其中一张桌子有23个活动元组，但有16845个死元组正在等待真空。太疯狂了！ 当测试运行完成并且数据库服务器处于空闲状态时，自动吸尘器将启动，这不是我想要的，因为当失效的元组的数量超过20％的活动元组+ 50时，我希望自动吸尘器启动，因为数据库已经配置。服务器空闲时自动清理对我来说毫无用处，因为生产服务器在持续的时间内有望达到每秒数千次的更新，这就是即使服务器负载时我也需要运行自动清理的原因。 有什么我想念的吗？在服务器负载较重时，如何强制自动吸尘器运行？ 更新资料 难道这是一个锁定问题？有问题的表是汇总表，这些表是通过插入后触发器填充的。这些表被锁定为SHARE ROW EXCLUSIVE模式，以防止并发写入同一行。

42 postgresql  performance  performance-testing  vacuum 

我在Ubuntu上使用PostgreSQL 9.1。是否VACUUM ANALYZE仍建议使用预定时间，还是自动真空足以满足所有需求？ 如果答案是“取决于”，则： 我的数据库比较大（压缩的转储大小为30 GiB，数据目录为200 GiB） 我将ETL输入数据库，每周导入近300万行 更改最频繁的表都从主表继承，主表中没有数据（数据按周划分） 我创建每小时汇总，并从那里创建每日，每周和每月报告 我要问的是因为计划安排VACUUM ANALYZE正在影响我的报告。它运行了5个多小时，本周我不得不杀死它两次，因为它影响了常规数据库的导入。check_postgres不会报告数据库有任何重大膨胀，所以这并不是真正的问题。 从文档中，autovacuum还应注意事务ID的回绕。问题是：我还需要一个VACUUM ANALYZE吗？

38 postgresql  etl  vacuum 

我已经找到了一百万个有关如何设置Autovacuum的配置设置的示例，但是似乎找不到如何列出当前配置的示例。 Postgres 9.1是我最感兴趣的版本。

36 postgresql  postgresql-9.1  vacuum 

我有一张桌子占用了我们服务器上接近90％的高清空间。我决定删除几列以释放空间。但是我需要将空间返回给操作系统。但是，问题是我不确定如果我运行VACUUM FULL并且没有足够的可用空间来复制表，会发生什么。 我知道不应该使用VACUUM FULL，但是我认为这是这种情况下的最佳选择。 任何想法，将不胜感激。 我正在使用PostgreSQL 9.0.6

27 postgresql  delete  alter-table  database-size  vacuum 

VACUUM除某些特殊情况外，通常不会将磁盘空间返回给操作系统。 从文档： 标准形式的VACUUM删除表和索引中的死行版本，并标记可用于将来重用的空间。但是，它不会将空间返回给操作系统，除非在特殊情况下，表末尾的一个或多个页面变得完全空闲，并且可以轻松获得独占表锁。相反，VACUUM FULL通过编写没有死角的表文件的全新版本来主动压缩表。这样可以最大程度地减少表的大小，但是会花费很长时间。在操作完成之前，表的新副本还需要额外的磁盘空间。 问题是：如何实现该数据库状态one or more pages at the end of a table become entirely free？可以通过完成此操作VACUUM FULL，但是我没有足够的空间来实现它。那么还有其他可能性吗？

21 postgresql  postgresql-9.2  maintenance  disk-space  vacuum 

在2015年的re：Invent谈话中，AWS提到，不仅应在更新或删除之后运行真空，而且还应在插入之后运行真空。这是演讲的相关部分： http://www.youtube.com/watch?v=tZXp19q8RFo&t=16m2s 假设即使块仅接收插入，也必须对其进行一些清理，并且可以在第一次选择块时（降低读取速度）或在真空期间进行清理。这是真的吗？如果是，那么到底必须执行什么清理工作？

19 postgresql  postgresql-performance  vacuum 

有人可以解释VACUUMPostgreSQL中这些类型之间的区别吗？ 我读了文档，但是它只是说FULL锁定表并FREEZE“冻结”元组。我认为是一样的。我错了吗？

18 postgresql  vacuum 

我管理着一个大型的数据库（数百个演出），其中包含具有各种角色的表，其中一些表拥有数百万条记录。一些表只接收大量的插入和删除，另一些表则接收大量的插入和删除。 数据库在带有16 GB RAM的Debian 6.0 amd64系统上的PostgreSQL 8.4上运行。 问题有时是在桌子上进行自动真空处理，需要很长时间（几天）才能完成。我希望能够粗略地知道一个特定的真空命令将花费多少时间，以便能够决定是否取消它。另外，如果有用于postgres真空操作的进度指示器，那将真的很有帮助。 编辑： 我不是在寻找防弹解决方案。只需给出死元组数或必要的I / O字节数的粗略提示就可以确定。VACUUM无论何时何地都不知道，真是令人讨厌。 我已经看到pg_catalog.pg_stat_all_tables有一个死元组数列。因此，即使有可能需要对表进行估算，也可以进行估算ANALYZE。在另一方面，autovacuum_vacuum_threshold与autovacuum_vacuum_scale_factor设置单独证明Postgres的本身知道一些有关变化对表的数量，并可能将其放在了DBA手中了。 我不确定要运行什么查询，因为在运行时VACUUM VERBOSE，我不仅看到表，而且也正在处理它们的索引。

18 postgresql  vacuum 

我使用的软件可以创建一个大型的PostgreSQL数据库（其中有一个包含一百万行的表），而开发人员则说我应该VACUUM并ANALYZE定期这样做。但是PostgreSQL数据库默认设置是autovacuum打开的。 我应该完全吸尘/分析吗？有什么好处？自动和手动吸尘有什么区别 例如，在Pgadmin3中，我有这个：

15 postgresql  maintenance  vacuum 

我有一个表，其中数据占用200 GB的大小，表上的6个索引占用180 GB的大小。它已膨胀了30％，所以我想回收它占用的多余空间。它聚集在job_id_idx索引上。 所以要回收空间，我需要使用clustercommand还是vacuum fullcommand？ 这两个命令有什么区别？ 是vacuum full为了通过一些列相同cluster的命令？ 是否在两个命令中都重新创建了索引？ 就我而言，哪一个会更快？ PostgreSQL数据库版本为9.1

13 postgresql  postgresql-9.1  clustered-index  vacuum 

我有一个经常更新的表，其中包含2.4亿行（并且还在不断增长）。每三小时插入150万行，删除150万行。当我将群集移至SSD时，此批量插入（使用副本）的时间从22分钟减少到2.3分钟。删除时间也得到了改善。我计划每两个小时或每小时进行一次批量更新。 尽管现在的性能（在SSD之后）可以与更频繁的更新兼容，但我已经读到了一些有关由于有限的NAND耐久性和写入放大而导致SSD死亡的恐怖故事。由于固态硬盘价格昂贵，我想将其淘汰时间推向未来。因此，我的问题是：磁盘文件在删除和随后的清理中到底发生了什么？我猜有两个磁盘写操作，一个将行标记为已删除，另一个在清理时将其标记为可覆盖。如果不是在每个批量插入/删除操作中对创建和删除表进行分区而不是删除和清理，我将使SSD的磨损最小化吗？

13 postgresql  partitioning  delete  storage  vacuum 

在某些场合，并作出巨大的后update，insert或delete从一个表，我已经开始了VACUUM FULL ANALYZE，以确保DB没有得到太臃肿。在生产数据库中进行操作使我发现这不是一个好主意，因为我可能会长时间阻塞该表。因此，我取消了此过程，可能只是尝试了一下VACUUM（未完成），或者AUTOVACUUM稍后再做任何可以做的事情。 问题是：如果我在中途停止VACUUM或AUTOVACUUM，是否已经完成所有处理？ 例如，如果VACUUM已经找到1 M死行而我停止了，所有这些信息会丢失吗？VACUUM是否以完全事务性的方式工作（“全部或全部”，就像很多PostgreSQL进程一样）？ 如果可以安全地中断VACUUM而不会丢失所有工作，那么有什么方法可以使vacuum工作逐步进行？[工作100毫秒，停止，等待10毫秒，以便不阻塞世界其他地方...依此类推]。我知道您可以通过调整自动真空参数来完成部分操作，但是我正在考虑能够以编程方式控制此操作，以便能够在特定时间/特定条件下执行此操作。 注意：在这种情况下，停止/取消/终止进程意味着： 如果使用pgAdmin，请按“取消查询”按钮。 如果以编程方式工作，请调用pg_cancel_backend（）。 我认为两者是等效的。我还没有使用过任何shell /系统级的kill命令。

13 postgresql  vacuum  maintenance  autovacuum 

我们在Windows上使用Postgres 9.2来存储低频时间序列数据：我们每周7天，每24小时每秒每秒插入约2000行，而没有停机。DELETE每隔10分钟左右在表上运行一次，以将表的长度保持固定的天数。最终是相当稳定的9亿行。（对于那些有兴趣，SELECT，INSERT，DELETE都是高性能）。 因此DELETE，在删除行时不会释放磁盘空间。为此，我们需要VACUUM运行。 我查询，pg_stat_user_tables并且VACUUM似乎从未运行过。 我从各种文档（http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html）了解到： 我们似乎启用了自动真空，并且它正在其他表上运行。 auto-vacuum不会运行FULL，并且不应在表上要求排他锁。 有谁想到为什么自动真空不运行？这纯粹是因为桌子一直在忙吗？ 它是值得的运行VACUUM后，每DELETE在这种情况下（其中每10分钟一班）？ 编辑： 通过下面的SO链接使用SQL查询： -[ RECORD 2 ]---+--------------------------- schemaname | stats relname | statistic_values_by_sec last_vacuum | last_autovacuum | n_tup | 932,315,264 dead_tup | 940,727,818 av_threshold | 186,463,103 expect_av | * 和原始输出： -[ RECORD 3 ]-----+--------------------------- relid | 501908 schemaname | stats relname | …

11 postgresql  vacuum 

我有大量更新/访问的表，其中存储了序列化的Java对象。它们在表中停留了2-3个小时（在此期间也正在更新），然后将其删除。表的大小约为300MB。我发现它经常被抽空，想知道改变它fillfactor是否有帮助？

10 postgresql  configuration  nosql  vacuum  fill-factor 

我在摆弄，VACUUM并注意到一些意外的行为，其中SELECT从表中读取行似乎减少了VACUUM以后的工作量。 测试数据 注意：自动真空已禁用 CREATE TABLE numbers (num bigint); ALTER TABLE numbers SET ( autovacuum_enabled = 'f', toast.autovacuum_enabled = 'f' ); INSERT INTO numbers SELECT generate_series(1, 5000); 试验1 现在，我们对所有行进行更新， UPDATE numbers SET num = 0; 当我们跑步时，VACUUM (VERBOSE) numbers;我们得到了， INFO: vacuuming "public.numbers" INFO: "numbers": removed 5000 row versions in 23 pages INFO: …

9 postgresql  select  vacuum  postgresql-11