Re: Backend memory dump analysis

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Backend memory dump analysis
Дата
Msg-id 20180323181157.stgrj3ygc3zbwxb5@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Backend memory dump analysis  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Ответы Re: Backend memory dump analysis  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2018-03-23 18:05:38 +0000, Vladimir Sitnikov wrote:
> Andres>The overhead required for it (in cycles, in higher memory usage due
> to
> additional bookeeping
> 
> Does that mean the memory contexts are unparseable? (there's not enough
> information to enumerate contents)

You can enumerate them (that's what the stats dump you're referring to
do), but you can't associate them with individual statements etc without
further bookepping.


> What if memory dump is produced by walking the C structures?

We don't know the types of individual allocations.


> For instance, I assume statament cache is stored in some sort of a hash
> table, so there should be a way to enumerate it in a programmatic way. Of
> course it would take time, however I do not think it creates cpu/memory
> overheads. The overhead is to maintain "walker" code.

Sure, you could, entirely independent of the memory stats dump, do
that. But what information would you actually gain from it? Which row
something in the catcache belongs to isn't *that* interesting.

- Andres


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

Предыдущее
От: Vladimir Sitnikov
Дата:
Сообщение: Re: Backend memory dump analysis
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Backend memory dump analysis