Re: possible memory leak in VACUUM ANALYZE

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: possible memory leak in VACUUM ANALYZE
Дата
Msg-id 20230210201839.qygmv7y2afbtl6jy@awork3.anarazel.de
обсуждение исходный текст
Ответ на possible memory leak in VACUUM ANALYZE  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: possible memory leak in VACUUM ANALYZE  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
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.

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: possible memory leak in VACUUM ANALYZE