POSTGRE -PG_STATITATINT ADUCUM超时

发布于 2025-02-05 20:19:29 字数 1201 浏览 3 评论 0 原文

在我的Aurora Postgres服务器中,我每分钟都会不断看到真空超时:

autovacuum: VACUUM pg_catalog.pg_statistic 

我尝试手动进行操作并进行以下输出:

INFO:  vacuuming "pg_catalog.pg_statistic"
INFO:  "pg_statistic": found 0 removable, 409109 nonremovable row versions in 19981 out of 19990 pages
DETAIL:  408390 dead row versions cannot be removed yet, oldest xmin: 4230263474
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 9 frozen pages.
0 pages are entirely empty.
CPU: user: 0.06 s, system: 0.00 s, elapsed: 0.07 s.
INFO:  vacuuming "pg_toast.pg_toast_2619"
INFO:  "pg_toast_2619": found 0 removable, 272673 nonremovable row versions in 61558 out of 61558 pages
DETAIL:  219 dead row versions cannot be removed yet, oldest xmin: 4230263474
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.14 s, system: 0.00 s, elapsed: 0.14 s.
VACUUM

Query returned successfully in 5 secs 55 msec.

任何人都可以指出发生这种情况的原因吗?

In my Aurora Postgres server I continuously see a vacuum timeout every minute for the following:

autovacuum: VACUUM pg_catalog.pg_statistic 

I tried doing it manually and got following output:

INFO:  vacuuming "pg_catalog.pg_statistic"
INFO:  "pg_statistic": found 0 removable, 409109 nonremovable row versions in 19981 out of 19990 pages
DETAIL:  408390 dead row versions cannot be removed yet, oldest xmin: 4230263474
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 9 frozen pages.
0 pages are entirely empty.
CPU: user: 0.06 s, system: 0.00 s, elapsed: 0.07 s.
INFO:  vacuuming "pg_toast.pg_toast_2619"
INFO:  "pg_toast_2619": found 0 removable, 272673 nonremovable row versions in 61558 out of 61558 pages
DETAIL:  219 dead row versions cannot be removed yet, oldest xmin: 4230263474
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.14 s, system: 0.00 s, elapsed: 0.14 s.
VACUUM

Query returned successfully in 5 secs 55 msec.

Anyone can point to the reason why this is happening?

enter image description here

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

情定在深秋 2025-02-12 20:19:29

我认为您的Autovacuum可能也可以正常工作,可能只是AWS的指标

一个过程正在以基于成本的真空延迟点等待。

最相似的设置是 autovacuum_vacuum_cost_delay 存在于PostgreSQL中。

想要减慢自动赛。当完成 autovacuum_vacuum_cost_limit 成本时,Autovacuum将为许多毫秒而睡觉。

我们可以尝试使用 PG_STAT_USER_TABLES 来验证Autovacuum的最新时间。

SELECT
  schemaname, relname,
  last_autovacuum,
  last_autoanalyze
FROM pg_stat_user_tables;

I think your autovacuum might work as well, Timeout:VacuumDelay might only be a metric From AWS

A process is waiting in a cost-based vacuum delay point.

The most similar setting is autovacuum_vacuum_cost_delay which exists in PostgreSQL.

That want to slow down autovacuum. autovacuum will sleep for these many milliseconds when a cleanup reaching autovacuum_vacuum_cost_limit cost is done.

We can try to use pg_stat_user_tables to verify the latest time of autovacuum.

SELECT
  schemaname, relname,
  last_autovacuum,
  last_autoanalyze
FROM pg_stat_user_tables;
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文