Question

我正在经历一个场景，我根本不知道我的问题的线索。

我有一个名为names的表（列名和时间）。该表每隔一分钟插入许多行。并且这些插入的记录将在特定时间间隔内删除。所以，最后我停止插入数据并删除了表中的所有行。

我的数据库版本详细信息

impss=# SELECT  version();
                                           version                                            
----------------------------------------------------------------------------------------------
 PostgreSQL 8.3.7 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2
(1 row)

但是当我发出查询以查找表的大小时，我仍然会得到一些大小。

impss=# SELECT  pg_size_pretty( pg_total_relation_size('names')) ;
 pg_size_pretty 
----------------
 1504 kB
(1 row)

首先问题为什么它仍然显示了一些大小，虽然我已经从表中删除了所有记录。

要查找上次自动清空的时间，我已发出以下查询：

当前时间

impss=# select now(); 
               now                
----------------------------------
 2012-11-08 20:21:10.550434+05:30
(1 row)

impss=# SELECT last_autovacuum  from pg_stat_user_tables where relname='names';
         last_autovacuum          
----------------------------------
 2012-11-08 17:51:31.995618+05:30

第二个问题：为什么在此之后没有执行autovacuum进程，尽管我的数据库不是很忙，我已经停止了对该表的所有事务。

所以，请告诉我是否需要进行任何特定配置来进行频繁的真空处理，以便在记录被删除后我可以取回所有空间。

Answer 1

第一个查询 - autovacuum没有调用VACUUM FULL - 因此它对关系大小没有影响（通常，但是当没有其他请求访问关系时，它可以修剪从一个到另一个生存元组的关系文件真空执行的时刻），第二个查询 - 当autovacuum_vacuum_threshold行被修改并且修改的行/所有行高于autovacuum_vacuum_scale_factor时执行autovacuum。这两个值都在postgresql.conf中，默认值为50行和20％。

Autovacuum执行并不依赖于当前的数据库负载 - 它仅取决于更新/删除的行数。

Answer 2

你正处于8.3系列的一个非常古老的版本，这是它自我过时和即将结束的生命终结。请参阅postgresql.org/support/versioning。紧急升级到8.3.21然后准备升级到更新的主要版本。阅读每个主要版本的发行说明，尤其是“迁移”部分。

在你的情况下，版本是相关的，因为autovacuum自8.3以来已经有了很大的改进。例如，8.4摆脱了自由空间地图的手动管理。在8.3及以下版本中，您需要将max_fsm_pages（注意：有意链接到8.3文档）保持得足够高，vacuum可以跟踪表格中的所有可用空间。如果你超过max_fsm_pages，你就会开始失去空间并需要VACUUM FULL来恢复。当然，8.3 VACUUM FULL很糟糕，很慢，有时您需要REINDEX，所以最好使用CLUSTER。

VACUUM通常不会移动元组以允许它截断文件，但是在没有可用空间映射问题的较新版本上，不太可能出现错误的max_fsm_pages设置将导致无限制的表增长;它会稳定下来。

严重。升级。

为了缓解，请计划一些停机时间。检查日志中是否有关于max_fsm_pages的警告，并在需要时增加警告，然后CLUSTER您的表格。做好准备需要一段时间。还要调整autovacuum以更积极地运行。

为什么autovacuum进程无法恢复内存

2 个答案: