Re: possible memory leak in VACUUM ANALYZE

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: possible memory leak in VACUUM ANALYZE
Date: 2023-02-10 20:23:11
Message-ID: CAFj8pRBO9kDK0FxVUUzJN816=D92G5Zcm9MC78pXgcC7J772Aw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

pá 10. 2. 2023 v 21:18 odesílatel Andres Freund <andres(at)anarazel(dot)de> napsal:

> Hi,
>
> On 2023-02-10 21:09:06 +0100, Pavel Stehule wrote:
> > Just a small note - I executed VACUUM ANALYZE on one customer's database,
> > and I had to cancel it after a few hours, because it had more than 20GB
> RAM
> > (almost all physical RAM).
>
> Just to make sure: You're certain this was an actual memory leak, not just
> vacuum ending up having referenced all of shared_buffers? Unless you use
> huge
> pages, RSS increases over time, as a process touched more and more pages in
> shared memory. Of course that couldn't explain rising above
> shared_buffers +
> overhead.
>
>
> > The memory leak is probably not too big. This database is a little bit
> > unusual. This one database has more than 1 800 000 tables. and the same
> > number of indexes.
>
> If you have 1.8 million tables in a single database, what you saw might
> just
> have been the size of the relation and catalog caches.
>

can be

Regards

Pavel

>
> Greetings,
>
> Andres Freund
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-02-10 20:50:20 Killing off removed rels properly
Previous Message Andres Freund 2023-02-10 20:18:39 Re: possible memory leak in VACUUM ANALYZE