Re: Memory Leakage Problem

From: John Sidney-Woollett <johnsw(at)wardbrook(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Memory Leakage Problem
Date: 2005-12-14 13:52:00
Message-ID: 43A02380.6070203@wardbrook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

Martijn

Thanks for the tip.

Since the connections on this server are from slon, I'm hoping that they
hand around for a *long* time, and long enough to take a look to see
what is going on.

John

Martijn van Oosterhout wrote:
> On Tue, Dec 13, 2005 at 04:37:42PM -0000, John Sidney-Woollett wrote:
>
>>I'll run this over the next few days and especially as the server starts
>>bogging down to see if it identifies the culprit.
>>
>>Is it possible to grab memory outsize of a processes space? Or would a
>>leak always show up by an ever increasing VSZ amount?
>
>
> The only way to know what a process can access is by looking in
> /proc/<pid>/maps. This lists all the memory ranges a process can
> access. The thing about postgres is that each backend dies when the
> connection closes, so only a handful of processes are going to be
> around long enough to cause a problem.
>
> The ones you need to look at are the number of mappings with a
> zero-inode excluding the shared memory segment. A diff between two days
> might tell you which segments are growing. Must be for exactly the same
> process to be meaningful.
>
> Have a nice day,

In response to

Browse pgsql-general by date

  From Date Subject
Next Message hubert depesz lubaczewski 2005-12-14 14:02:48 outdated (bad) information in pg_stat_activity
Previous Message Jerry LeVan 2005-12-14 13:49:36 ANN: PgBrowse 1.4

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-12-14 15:26:53 Re: Convert IN sublink to join
Previous Message francisco.santos 2005-12-14 13:27:21 Convert IN sublink to join