标签: autovacuum

我将 9.4 postgresql 集群升级到 9.6。（通过 pg_upgrade，所以我的 db stats 没有移动到新集群）我有一个大表（大约 450M 记录）。这个表在我的代码中经常使用（很多选择和更少的 upserts）。当我启动我的 postgres 服务时，Postgres 会自动启动 autovacuum，它会锁定我的桌子。所以我不能做任何事情：既不截断表也不手动分析它。我试图在我的配置文件中设置 autovacuum=off，但它没有帮助（为什么？！我当然重新启动了服务器）

更新：我的目标是尽快开始使用该表。截断会有所帮助（因为表将是空的），分析应该会有所帮助（Postgres 将开始使用适当的索引）

什么是最快的方法：1）截断表或 2）分析表？任何帮助将非常感激。

更新： 这是查看锁的查询的输出：

SELECT psa.pid,granted,query FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid = psa.pid where locktype='relation';


  pid  | granted | query                                                                                                                          
-------+---------+---------------------------

 11831 | t       | autovacuum: VACUUM ANALYZE public.ig_tasks_users (to prevent wraparound)
 11831 | t       | autovacuum: VACUUM ANALYZE public.ig_tasks_users (to prevent wraparound)
 11831 | t       | autovacuum: VACUUM ANALYZE public.ig_tasks_users (to prevent wraparound)
 11831 | …

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

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

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

谢谢大家......

我对 postgresql 没有经验。

做了一个简单的命令

DELETE FROM table_name where some_condition;

涉及数千行。但实际上在该命令之后，磁盘空间变得更小。

知道出了什么问题吗？我启用了 autovacuum = on 并尝试执行 'VACUUM FULL;' 但这消耗了我的整个磁盘空间。

我想做的很简单。删除行并获取空间。涉及的空间很大，机器上没有多少空间。有没有办法做到这一点？

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

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

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

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

谢谢！

我的架构中有一个表没有自动恢复.如果我VACUUM posts;在桌子上运行真空过程很好,但autovacuum守护进程从来没有因为某种原因吸尘.有没有办法找出原因？可能的原因是什么？

我们的 Postgres 数据库（托管在具有 1 个 CPU、3.7 GB RAM 的 Google Cloud SQL 上，见下文）主要由一个大约 90GB 的大表组成，大约有大约 6000 万行。使用模式几乎完全由附加和靠近表末尾的一些索引读取组成。有时会删除一些用户，删除散布在表中的一小部分行。

这一切正常，但每隔几个月就会在该表上触发自动清理，这会显着影响我们服务的性能约 8 小时：

• 在 autovacuum 期间（几个小时），存储使用量增加了约 1GB，然后慢慢恢复到以前的值（由于 autovacuum 释放页面，最终可能会低于它）
• 数据库 CPU 利用率从 <10% 跃升至 ~20%
• 磁盘读/写操作从接近零增加到约 50/秒
• 数据库内存略有增加，但保持在 2GB 以下
• 正如预期的那样，事务/秒和入口/出口字节也相当不受影响

这会在 autovacuum 期间将我们服务的第 95 个延迟百分位数从 ~100ms 增加到 ~0.5-1s，从而触发我们的监控。该服务每秒处理大约 10 个请求，每个请求由一些简单的 DB 读/写组成，每个请求的延迟通常为 2-3 毫秒。

以下是一些说明问题的监控屏幕截图：

数据库配置相当普通：

记录此 autovacuum 过程的日志条目如下所示：

system usage: CPU 470.10s/358.74u sec elapsed 38004.58 sec
avg read rate: 2.491 MB/s, avg write rate: 2.247 MB/s
buffer usage: 8480213 hits, 12117505 …

我们有一项工作需要通过 REST API 插入数百万条记录。我们发现，一旦插入几百万条记录后，服务就会挂起并停止响应。

我怀疑问题出在 Postgres DB 上，所以我抓取了日志（来自 AWS RDS）并发现了以下相关行：

2022-09-08 19:17:58 UTC::@:[26730]:LOG:  automatic vacuum of table "xxx.xxx.edges": index scans: 1
    pages: 0 removed, 2659041 remain, 0 skipped due to pins, 321741 skipped frozen
    tuples: 4680884 removed, 48758705 remain, 657299 are dead but not yet removable, oldest xmin: 458583508
    index scan needed: 268594 pages from table (10.10% of total) had 4843221 dead item identifiers removed
    index "edges_pkey": pages: 398515 in total, 0 newly deleted, 0 currently deleted, 0 reusable
    index …

我们在一台较小的数据库机器上运行了一个运行时间非常长的 autovacuum 进程，我们相信该机器已经使用了很多Aurora:StorageIOUsage： 我们通过SELECT * FROM pg_stat_activity WHERE wait_event_type = 'IO'; 反复运行并查看以下结果来确定这一点。

 datid  |  datname |  pid  | usesysid |  usename  | application_name |  client_addr   | client_hostname | client_port |         backend_start         |          xact_start           |          query_start          |         state_change          | wait_event_type |  wait_event  | state  | backend_xid | backend_xmin |                                                                                query                                                                                 |   backend_type    
--------+----------------------------+-------+----------+-----------+------------------+----------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------+-----------------+--------------+--------+-------------+--------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------
 398954 | postgres | 17582 |          |           |                  |                |                 |             | 2022-09-29 18:45:55.364654+00 | 2022-09-29 18:46:20.253107+00 | 2022-09-29 18:46:20.253107+00 | 2022-09-29 18:46:20.253108+00 | IO …