X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 330359DC9C3
	for <pgsql-general-postgresql.org@localhost.postgresql.org>;
	Wed, 14 Dec 2005 09:46:04 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 06149-04
	for <pgsql-general-postgresql.org@localhost.postgresql.org>;
	Wed, 14 Dec 2005 09:46:06 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from mercury.wardbrook.com (host-84-9-98-118.bulldogdsl.com
	[84.9.98.118]) by postgresql.org (Postfix) with ESMTP id 535D69DC99D
	for <pgsql-general@postgresql.org>;
	Wed, 14 Dec 2005 09:45:59 -0400 (AST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mercury.wardbrook.com (Postfix) with ESMTP
	id C32AD532EB; Wed, 14 Dec 2005 13:43:16 +0000 (GMT)
Received: by mercury.wardbrook.com (Postfix, from userid 505)
	id 99A34532EF; Wed, 14 Dec 2005 13:43:15 +0000 (GMT)
Received: from [192.168.0.64] (unknown [192.168.0.1])
	by mercury.wardbrook.com (Postfix) with ESMTP
	id 6CAAB532EB; Wed, 14 Dec 2005 13:43:14 +0000 (GMT)
Message-ID: <43A02380.6070203@wardbrook.com>
Date: Wed, 14 Dec 2005 13:52:00 +0000
From: John Sidney-Woollett <johnsw@wardbrook.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martijn van Oosterhout <kleptog@svana.org>
Cc: pgsql general <pgsql-general@postgresql.org>
Subject: Re: Memory Leakage Problem
References: <c10e7feb0512071825h30c93c00kdf5ea2a11e613f0b@mail.gmail.com>
	<b918cf3d0512071946m3cbfc630y679e0350a7f6b864@mail.gmail.com>
	<6353.1134016733@sss.pgh.pa.us>
	<b918cf3d0512080600q5c841fc8lecd96c3bad66cfdc@mail.gmail.com>
	<439DDB49.3000905@freedomhealthcare.org>
	<439E7B7A.9080205@wardbrook.com> <3666.1134460063@sss.pgh.pa.us>
	<439E80B1.8030800@wardbrook.com> <6375.1134486792@sss.pgh.pa.us>
	<6597.195.152.219.3.1134491862.squirrel@mercury.wardbrook.com>
	<20051214092137.GA16967@svana.org>
In-Reply-To: <20051214092137.GA16967@svana.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0 required=5 tests=[none]
X-Spam-Score: 0
X-Spam-Level: 
X-Archive-Number: 200512/692
X-Sequence-Number: 88255

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,