Re: possible memory leak in VACUUM ANALYZE
От | Pavel Stehule |
---|---|
Тема | Re: possible memory leak in VACUUM ANALYZE |
Дата | |
Msg-id | CAFj8pRBO9kDK0FxVUUzJN816=D92G5Zcm9MC78pXgcC7J772Aw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: possible memory leak in VACUUM ANALYZE (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: possible memory leak in VACUUM ANALYZE
|
Список | pgsql-hackers |
pá 10. 2. 2023 v 21:18 odesílatel Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: