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-25 19:34:27
Message-ID: 21142.1472153667@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:
>> It would be worth using plain old top to watch this process. We have
>> enough experience with that to be pretty sure how to interpret its
>> numbers: "RES minus SHR" is the value to be worried about.

> Sure thing. https://gist.github.com/luhn/e09522d524354d96d297b153d1479c13#file-top-txt

> RES - SHR is showing a similar increase to what smem is reporting.

Hm, yeah, and the VIRT column agrees --- so 100MB of non-shared
memory went somewhere. Seems like a lot.

If you have debug symbols installed for this build, you could try
doing

gdb /path/to/postgres processID
gdb> call MemoryContextStats(TopMemoryContext)
gdb> quit

(when the process has reached an idle but bloated state) and seeing what
gets printed to the process's stderr. (You need to have launched the
postmaster with its stderr directed to a file, not to /dev/null.)
That would provide a better clue about what's eating space.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2016-08-25 19:57:16 Re: LOG: could not fork new process for connection: Cannot allocate memory
Previous Message Ahsan Ali 2016-08-25 18:49:17 LOG: could not fork new process for connection: Cannot allocate memory