Re: Backend memory dump analysis - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Backend memory dump analysis
Date
Msg-id 20180323181157.stgrj3ygc3zbwxb5@alap3.anarazel.de
Whole thread Raw
In response to Re: Backend memory dump analysis  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Responses Re: Backend memory dump analysis  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Vladimir Sitnikov
Date:
Subject: Re: Backend memory dump analysis
Next
From: Tom Lane
Date:
Subject: Re: Backend memory dump analysis