Re: Understanding Postgres Memory Usage

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

Okay, here's the output:
https://gist.github.com/luhn/a39db625ba5eed90946dd4a196d12220

— Theron

On Thu, Aug 25, 2016 at 12:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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/e09522d524354d96d297b153d1479c
> 13#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 Oleg Bartunov 2016-08-25 20:30:11 Fwd: [Snowball-discuss] Greek stemmer
Previous Message John R Pierce 2016-08-25 19:57:16 Re: LOG: could not fork new process for connection: Cannot allocate memory