From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "depesz(at)depesz(dot)com" <depesz(at)depesz(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: What is pg backend using memory for? |
Date: | 2013-04-10 07:36:59 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B057DB263@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
hubert depesz lubaczewski wrote:
> So, I checked a backend on Linux, and found such thing:
> 2ba63c797000-2ba63fa68000 rw-p 2ba63c797000 00:00 0
> Size: 52036 kB
> Rss: 51336 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 51336 kB
> Swap: 0 kB
> Pss: 51336 kB
>
> (this is part of /proc/<pid>/smaps).
>
> This is not shared memory, so it's local. It's not related to any files (in such case first line would
> have path to file).
>
> What's more - this backend, during getting smaps copy was idle, and it's not stats manager, or
> anything like this.
>
> How can this be diagnosed, to find out why there is so much private
> memory?
>
> In case it matters: it's pg 9.1.6 on linux 2.6.18-164.2.1.el5
What libraries are loaded in this backend (lsof)?
Maybe it's something non-PostgreSQL that's hogging the memory.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Johann Spies | 2013-04-10 07:58:05 | Re: Backup advice |
Previous Message | Albe Laurenz | 2013-04-10 07:22:46 | Re: After dump/restoring from 32bit 8.4-windows to 64bit 9.2.4-linux experiencing 10x slowdown on queries |