Re: Memory Leakage Problem

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: John Sidney-Woollett <johnsw(at)wardbrook(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Memory Leakage Problem
Date: 2005-12-14 09:21:41
Message-ID: 20051214092137.GA16967@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

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,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-12-14 11:04:58 Re: timestamp <-> ctime conversion question...
Previous Message surabhi.ahuja 2005-12-14 09:13:16 valgrind output

Browse pgsql-performance by date

  From Date Subject
Next Message francisco.santos 2005-12-14 13:27:21 Convert IN sublink to join
Previous Message Mark Kirkwood 2005-12-14 07:28:56 Re: SAN/NAS options