RE: Autovacuum, dead tuples and bloat

Поиск
Список
Период
Сортировка
От Shenavai, Manuel
Тема RE: Autovacuum, dead tuples and bloat
Дата
Msg-id AM9PR02MB7410F50DD4C2AFBD1E6C9032E8CA2@AM9PR02MB7410.eurprd02.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Autovacuum, dead tuples and bloat  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: Autovacuum, dead tuples and bloat
Список pgsql-general
Thanks for the suggestion. This is what I found:

- pg_locks  shows only one entry for my DB (I filtered by db oid). The entry is related to the relation "pg_locks"
(AccessShareLock).
- pg_stat_activity shows ~30 connections (since the DB is in use, this is expected)

Is there anything specific I should further look into in these tables?

Regarding my last post: Did we see a problem in the logs I provided in my previous post? We have seen that there are
819294n_live_tup in the toast-table. Do we know how much space these tuple use?  Do we know how much space one tuple
use?

Best regards,
Manuel

-----Original Message-----
From: Adrian Klaver <adrian.klaver@aklaver.com>
Sent: 21 June 2024 22:39
To: Shenavai, Manuel <manuel.shenavai@sap.com>; Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>;
pgsql-general@lists.postgresql.org
Subject: Re: Autovacuum, dead tuples and bloat

On 6/21/24 12:31, Shenavai, Manuel wrote:
> Hi,
>
> Thanks for the suggestions. I found the following details to our
> autovacuum (see below). The related toast-table of my table shows some
> logs related the vacuum. This toast seems to consume all the data
> (27544451 pages * 8kb ≈ 210GB )

Those tuples(pages) are still live per the pg_stat entry in your second
post:

"n_dead_tup": 12,
"n_live_tup": 819294

So they are needed.

Now the question is why are they needed?

1) All transactions that touch that table are done and that is the data
that is left.

2) There are open transactions that still need to 'see' that data and
autovacuum cannot remove them yet. Take a look at:

pg_stat_activity:

https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW

and

pg_locks

https://www.postgresql.org/docs/current/view-pg-locks.html

to see if there is a process holding that data open.

>
> Any thoughts on this?
>
> Best regards,
> Manuel
>


--
Adrian Klaver
adrian.klaver@aklaver.com


В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump restores as expected on some machines and reports duplicate keys on others
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Autovacuum, dead tuples and bloat