相关疑难解决方法(0)

我在 Ubuntu 上使用 PostgreSQL 9.1。VACUUM ANALYZE仍然推荐预定，还是 autovacuum 足以满足所有需求？

如果答案是“视情况而定”，那么：

• 我有一个较大的数据库（30 GiB 压缩转储大小，200 GiB 数据目录）
• 我对数据库做 ETL，每周导入接近 300 万行
• 变化最频繁的表全部继承自一个主表，主表中没有数据（数据按周分区）
• 我创建每小时汇总，并从那里创建每日、每周和每月报告

我问是因为预定的时间VACUUM ANALYZE会影响我的报告。它运行了 5 个多小时，本周我不得不杀死它两次，因为它影响了常规的数据库导入。check_postgres不会报告数据库有任何显着膨胀，所以这不是真正的问题。

从文档中，autovacuum 也应该处理事务 ID 环绕。问题是：我还需要一个VACUUM ANALYZE吗？

我的问题有两个部分。

1. 有没有办法在 PostgreSQL 中指定数据库的初始大小？
2. 如果没有，当数据库随着时间的推移而增长时，您如何处理碎片？

我最近从 MSSQL 迁移到 Postgres，我们在 MSSQL 世界中创建数据库时所做的一件事是指定数据库和事务日志的初始大小。这减少了碎片并提高了性能，特别是如果事先知道数据库的“正常”大小。

我的数据库的性能随着大小的增长而下降。例如，我处理的工作负载通常需要 10 分钟。随着数据库的增长，这个时间会增加。执行 VACUUM、VACUUM FULL 和 VACUUM FULL ANALYZE 似乎不能解决问题。解决性能问题的是停止数据库，对驱动器进行碎片整理，然后进行 VACUUM FULL ANALYZE 使我的测试性能恢复到原来的 10 分钟。这让我怀疑是碎片化是导致我痛苦的原因。

我在 Postgres 中找不到任何关于保留表空间/数据库空间的参考。要么我使用了错误的术语，因此一无所获，要么在 Postgres 中有一种不同的方法来减轻文件系统碎片。

任何指针？

解决方案

提供的答案有助于确认我开始怀疑的内容。PostgreSQL 将数据库存储在多个文件中，这使得数据库可以增长而不必担心碎片化。默认行为是将这些文件与表数据一起打包，这对很少更改的表有好处，但对经常更新的表不利。

PostgreSQL 利用MVCC提供对表数据的并发访问。在此方案下，每次更新都会创建已更新行的新版本（这可能是通过时间戳或版本号，谁知道？）。旧数据不会立即删除，而是标记为删除。执行 VACUUM 操作时会发生实际删除。

这与填充因子有什么关系？表默认填充因子 100 完全填充表页，这反过来意味着表页内没有空间来保存更新的行，即更新的行将放置在与原始行不同的表页中。正如我的经验所示，这对性能不利。由于我的汇总表更新非常频繁（高达 1500 行/秒），我选择将填充因子设置为 20，即表的 20% 用于插入行数据，80% 用于更新数据。虽然这可能看起来过多，但为更新行保留的大量空间意味着更新行与原始行保持在同一页内，并且在 autovacuum 守护程序运行以删除过时行时表页未满。

为了“修复”我的数据库，我执行了以下操作。

1. 将我的汇总表的填充因子设置为 20。您可以在创建时通过将参数传递给CREATE TABLE或事后通过 ALTER TABLE 来执行此操作。我发出了以下 plpgsql 命令：ALTER TABLE "my_summary_table" SET (fillfactor = 20);
2. 发出 VACUUM FULL，因为这会写入一个全新版本的表文件，因此暗示会写入一个具有新填充因子的新表文件。

重新运行我的测试，即使数据库达到我需要的数百万行，我也没有发现性能下降。

TL;DR …

我已经大量更新/访问了存储序列化 java 对象的表。它们在表中停留 2-3 小时（在此期间也在更新），然后被删除。表的大小约为 300MB。我发现它非常非常频繁地被 VACUUMed 并想知道改变它fillfactor是否会有所帮助？