From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: possible memory leak in VACUUM ANALYZE |
Date: | 2023-02-10 22:01:31 |
Message-ID: | 20230210220131.GT1653@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 10, 2023 at 09:23:11PM +0100, Pavel Stehule wrote:
> pá 10. 2. 2023 v 21:18 odesílatel Andres Freund <andres(at)anarazel(dot)de> napsal:
> >
> > 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
Well, how big was shared_buffers on that instance ?
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2023-02-10 22:27:14 | Re: psql: Add role's membership options to the \du+ command |
Previous Message | Andres Freund | 2023-02-10 21:46:19 | Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry |