Re: Understanding Postgres Memory Usage - Mailing list pgsql-general

From Theron Luhn
Subject Re: Understanding Postgres Memory Usage
Date
Msg-id CAHYFdT-j=3MdKsGsfSjHsjECUwPk71u99GD7Es4afA11WGMz-Q@mail.gmail.com
Whole thread Raw
In response to Re: Understanding Postgres Memory Usage  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Understanding Postgres Memory Usage  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general


— Theron

On Thu, Aug 25, 2016 at 12:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Theron Luhn <theron@luhn.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

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: LOG: could not fork new process for connection: Cannot allocate memory
Next
From: Oleg Bartunov
Date:
Subject: Fwd: [Snowball-discuss] Greek stemmer