Re: Understanding Postgres Memory Usage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Theron Luhn <theron(at)luhn(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Understanding Postgres Memory Usage
Date: 2016-08-26 00:27:20
Message-ID: 31126.1472171240@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Theron Luhn <theron(at)luhn(dot)com> writes:
> Okay, here's the output:
> https://gist.github.com/luhn/a39db625ba5eed90946dd4a196d12220

Hm, well the only thing there that looks even slightly out of the
ordinary is the amount of free space in TopMemoryContext itself:

TopMemoryContext: 3525712 total in 432 blocks; 3444272 free (12654 chunks); 81440 used

Normally, TopMemoryContext doesn't get to more than a few hundred K,
and in the cases I've seen where it does, it's usually been because of
leaky coding that was allocating stuff there and never cleaning it up.
But you've got no more than the typical amount of space still allocated
there, which seems to kill the "leak in TopMemoryContext" theory.
And in any case there is nowhere near 100MB accounted for by the whole
dump.

Are you using any other PLs besides plpgsql? We've seen cases where
bloat occurred within plpython or plperl, and wasn't visible in this
dump because those languages don't use PG's memory management code.
Or maybe some nonstandard extension?

If not that, then I'd have to speculate that the query you're running is
triggering some bug or otherwise pathological behavior. Can you put
together a self-contained test case?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2016-08-26 00:28:29 Re: incorrect checksum detected on "global/pg_filenode.map" when VACUUM FULL is executed
Previous Message Ahsan Ali 2016-08-26 00:10:02 Re: LOG: could not fork new process for connection: Cannot allocate memory