标签: vacuum

我目前正在清理一个包含2个索引和2.5亿个活动行以及大约尽可能多的死行(或更多)的表.我从我的客户端计算机(笔记本电脑)向我的服务器发出了命令VACCUM FULL ANALYZE.它在过去3-4天左右开展业务; 我想知道它是否会很快结束,因为我还有很多工作要做!

该服务器具有四码Xeon 2.66 GHz处理器,12 GB或RAM以及RAID控制器,该控制器连接到RAID 1配置中的2 x 10K rpm 146 GB SAS HD; 它正在运行Suse Linux.我想知道...

现在,首先VACUUM postmaster流程似乎只使用一个核心.其次,我没有看到对I/O空闲时间比率的非常高的I/O写入.第三,从调用开始procinfo,我可以推断VACUUM进程花费大部分时间(88%)等待I/0.

那么为什么不通过线程使用更多内核来使RAID控制器过载(获得高I/O写入空闲比率)？如果I/O负载不高,为什么还在等待I/O？为什么手指上的所有这些功率/资源都不会更快？在我看来,VACUUM可以而且应该是多线程的,特别是如果它在一个巨大的桌子上工作,它是唯一一个工作!

另外,他们是一种配置postgresql.conf以让它多线程化这样的VACUUM的方法吗？我可以杀死它并仍然可以从部分清理中获益吗？我需要在那张桌子上工作.

[我正在使用PostgreSQL 8.1]

谢谢了

我想VACUUM在Perl上的SQLite数据库上的某个时间做,但它总是说

DBD :: SQLite :: db失败:无法在事务中使用VACUUM

那我该怎么做？

my %attr = ( RaiseError => 0, PrintError => 1, AutoCommit => 0 );
my $dbh = DBI->connect('dbi:SQLite:dbname='.$file'','',\%attr) 
    or die $DBI::errstr;

我在用AutoCommit => 0.而错误发生在:

$dbh->do('DELETE FROM soap');
$dbh->do('DELETE FROM result');
$dbh->commit; 
$dbh->do('VACUUM');

我正在考虑为即将到来的项目提供各种支持MVCC的数据库,PostgreSQL出现在我的雷达上.

我的程序的要求涉及大致如下的序列:

1. 从当前版本的数据库中读取一些信息,修改80-90%的数据并将其写回一个或多个事务中(想象一下像是在Conway的生命游戏中更新网格,其中包括网格的新旧状态是必要的).

2. 提交后等待1-2分钟.在此期间,客户端可以针对新数据发出读取.

3. 重复.

数据库将限制为2-4GB.

~90%的更改是对现有对象的更新,~5%将是新对象,~5%将被删除对象.

所以我的问题是,我可以合理地每1-2分钟运行一次普通的VACUUM命令作为步骤1.5,并且让PostgreSQL能够跟上每次可能发生的2-3 + GB的更改吗？

我的数据库中有一个表，该表占用161GB硬盘空间。200Gb硬盘仅剩5 GB可用空间。

1. 以下命令显示我的表占用了161GB硬盘空间，
   select pg_size_pretty(pg_total_relation_size('Employee'));

2. 表格中有近527行。现在我删除了250行。我再次检查了Employee的pg_total_relation_size。大小仍为161GB。

3. 看到上面查询的输出后，我运行了vacuum命令：
   VACUUM VERBOSE ANALYZE Employee;

4. 我检查了VACUUM是否确实发生了使用，
   SELECT relname, last_vacuum, last_autovacuum FROM pg_stat_user_tables; 我可以看到与运行VACUUM命令的时间相匹配的最后真空时间。

5. 我还运行以下命令，查看是否有死元组
   SELECT relname, n_dead_tup FROM pg_stat_user_tables；Employee表的n_dead_tup计数为0。

6. 如果我运行以上所有上述命令，
   select pg_size_pretty(pg_total_relation_size('Employee')); 它仍然显示161GB。

我能知道这背后的原因吗？还请纠正我有关如何释放interface_list的问题。

我们有一个非常大的表,分为月表.我们在postgresql.conf文件中没有设置autovacuum参数,因此默认情况下它使用默认参数.

过去几个月表table_201404,table_201403一旦传递就不会被写入或更新/删除,它们只会从历史数据中读取.为什么我们注意到在这些表上运行的autovacuum进程？是因为它们是主分区的一部分而PostgreSQL将这些表视为一个？

我们正在考虑将autovacuum_enabled设置为关闭这些过去的表,但我想先咨询Stackoverflow的智慧.

谢谢大家......

假设我定期将数据插入 SQLite 数据库，然后清除前 50% 的数据，但我不清理。

我现在是否有文件前 50% 的页面清零之类的内容？如果我添加另一批数据，我是否会填写那些清零的页面？

手册提到了数据碎片：

频繁的插入、更新和删除可能会导致数据库文件变得碎片化 - 单个表或索引的数据分散在数据库文件中。

VACUUM 确保每个表和索引在很大程度上连续存储在数据库文件中。在某些情况下，VACUUM 还可以减少数据库中部分填充的页数，从而进一步减小数据库文件的大小。

但这并不表明这必然会导致性能下降。它主要暗示了可以通过吸尘来节省浪费的空间。

严格连续页面中的数据是否有明显的性能提升？我可以期望具有大量碎片数据的数据库获得“糟糕”的性能吗？

我只是想检查一下我对这两件事的理解是否正确.如果相关,我使用的是Postgres 9.4.

我相信,当想要从文件系统中回收空间时,应该清空数据库,例如在删除表或大量行之后定期.

我认为应该在创建新索引后分析数据库,或者(在表中添加或删除大量行后)(定期)分析数据库,以便查询规划器可以进行良好的调用.

听起来不错吗？

来自 PostgreSQL（相对）新手的快速问题：

我们运行一个批处理，作为最后一步，删除大部分以前的批处理。

磁盘空间是一个问题，因此我们需要确保 PostgreSQL 自行清理。

除了强制 PostgreSQL 更快地进行垃圾收集之外，在批处理结束时显式调用 VACUUM 与让 auto-VACUUM 守护进程处理它之间有什么区别吗？有什么理由推荐一种方法与另一种方法吗？

谢谢！

这个 sql 查询通常只需要几分钟就可以运行：

update import_parts ip
set part_manufacturer_id = pslc.part_manufacturer_id
from parts.part_supplier_line_codes pslc
where trim(lower(ip.line_code)) = trim(lower(pslc.supplier_line_code))
and (ip.status is null or ip.status != '6')
and ip.distributor_id = pslc.distributor_id
and ip.distributor_id = 196;

但我注意到它有时会卡住并被 2 小时的 statement_timeout 自动取消。我注意到有几次，当它卡住时，autovacuum 正在运行，autovacuum 也需要很长时间才能完成运行。这是更新查询和 autovacuum 都在运行的一个实例，它们都需要很长时间才能完成运行：

^ 在这种情况下，autovacuum 在大约一个小时内完成运行，而更新查询在近 2 小时内完成运行。在其他情况下，更新查询超过 2 小时 statement_timeout，因此它会自动取消。

现在我的问题是，autovacuum (VACUUM) 是更新查询卡住或需要数小时才能完成运行的原因吗？如果是，我该怎么做才能防止更新查询卡住或变得如此缓慢？如果不是，您认为是什么导致更新查询卡住或变得如此缓慢？

我们使用的是 PostgreSQL 9.6.15

更新 1

我检查了我们的 RDS 实例是否耗尽了服务器资源。我们的实例大小是 db.t2.medium（2 个 vCPU，4GB RAM，1000 IOPS，存储类型为 iops SSD）。

这是过去 3 天的 cloudwatch 指标。请注意，在过去 3 天内，上面的更新 sql 查询卡住了多次。

更新 2

更新查询和 …

在生产环境中，我的数据库大小为 150 GB。从此表中删除了许多行，并对其应用了真空。现在我需要将未使用的空间从数据库释放到操作系统磁盘。因此需要应用 Vacuum Full。流复制在具有三个辅助节点的生产服务器上配置。最好的办法是什么？

1. 暂停复制并在主节点上运行 Vacuum FULL。然后再次开始复制。
2. 停止复制并在主节点上的 Vacuum FULL 后重新创建。