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

From Vladimir Sitnikov
Subject Re: Backend memory dump analysis
Date
Msg-id CAB=Je-GYt1hp+-GGu_9Ad9s4CFB-z+qmZj_Y9=AFEgpvQTDWVg@mail.gmail.com
Whole thread Raw
In response to Re: Backend memory dump analysis  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Backend memory dump analysis  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
It looks much better.

>While I didn't do anything about it here, I think it'd likely be a
>good idea for MemoryContextStats printout to truncate the context ID
>strings at 100 characters or so

It would be great if there was an option to show full sql.
For instance, current statistics is not sorted (should it be?), so it just prints the first 100 items no matter the size of entries.
Luckily there's a function that accepts "number of nodes to print" as an argument.
It would be better if it printed the 100 top consumers (including descendants) though.

I think it makes sense to move all the numerics to the front, so the numbers are located in the more or less the same columns.
Current output is hard to read as you basically have to search for "free" and "used" markers.

What do you think of (number of bytes are printed with 6 characters, and number of chunks with 2 characters)
  16384 total in  2 blocks;  12448 used;   3936 free ( 5 chunks): PL/pgSQL function tg_pslot_biu()
instead of
PL/pgSQL function tg_pslot_biu(): 16384 total in 2 blocks; 3936 free (5 chunks); 12448 used
?
I think "used memory" is more important than "free". As far as I understand, the main use-case is "analyze memory consumption", so one cares "what is consuming the memory" more than "what context have enough free space".

PS. "TopMemoryContext: 2143904 total" and "Grand total: 13115912 bytes" does confuse. It basically says "TopMemoryContext is 2MiB, and grant total is somehow 12MiB". It does not clarify if totals are "self memory" or "including descendant contexts". In your case the difference is 10MiB, and it is not that obvious why is that.

Vladimir

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: csv format for psql
Next
From: Tom Lane
Date:
Subject: Re: Backend memory dump analysis