Re: Backend memory dump analysis

From: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Backend memory dump analysis
Date: 2018-03-25 17:50:08
Message-ID: CAB=Je-EnvU5NjppmEmfo6BqtAnaC9kZyhpK0sBWVwQJ2fAX6kg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom>Well, as I said, you can do anything you want now in an extension.

That is true. However it basically means "everybody who cares to
troubleshoot the memory use of a production system should install an
extension".
Should
https://wiki.postgresql.org/wiki/Developer_FAQ#Examining_backend_memory_use
provide
a link to the extension then?

Tom>Actually the key number is the one that already is printed
Tom>first, ie the total space consumed by the context

The space used is more important than the context name itself.

What do you think of

8192 (2 blocks) CachedPlan: 1504 free (0 chunks); 6688 used: SELECT
(SELECT COUNT(*) FROM (SELECT * FROM new_test UNION ALL SELECT *
FROM new_test) ss)

?
PS. "1504 free (0 chunks)" reads odd.

Tom>Very occasionally, you might be interested in spotting contexts that
have
Tom>a disproportionate amount of free space, but IME that's seldom the main
Tom>issue.

Fully agree. That is why I suggest "total, used, free" order so it matches
the likelihood of usage.

Vladimir

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-25 18:05:26 Re: Backend memory dump analysis
Previous Message David Fetter 2018-03-25 17:42:49 Re: Proposal: http2 wire format