From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig@2ndQuadrant.com>
cc: Aaron Bono <aaron.bono@aranya.com>, Postgres <pgsql-admin@postgresql.org>
Subject: Re: Postgre Eating Up Too Much RAM
In-reply-to: <50A309DA.2040702@2ndQuadrant.com>
References: 
 <CAHfMse1Z+HGnDJ+2may-7vQgOcogjzuGYASB7yPE2CjAmGyCaQ@mail.gmail.com>
	<50A309DA.2040702@2ndQuadrant.com>
Comments: In-reply-to Craig Ringer <craig@2ndQuadrant.com>
	message dated "Wed, 14 Nov 2012 11:02:50 +0800"
Date: Tue, 13 Nov 2012 22:19:03 -0500
Message-ID: <6892.1352863143@sss.pgh.pa.us>

Craig Ringer <craig@2ndQuadrant.com> writes:
> On 11/14/2012 06:12 AM, Aaron Bono wrote:
>> Am I reading this right?  Are there individual connections using over
>> 300 MB or RAM by themselves?

> If I recall correctly, RSS is charged against a PostgreSQL back-end when
> it touches `shared_buffers`. So that doesn't necessarily mean that the
> back-end is using the full amount of memory listed as RSS.

Yeah.  Since Aaron's got shared_buffers set to 256MB, the shared memory
segment is something more than that (maybe 270-280MB, hard to be sure
without checking).  The RSS numbers probably count all or nearly all of
that for each process, but of course there's really only one copy of the
shared memory segment.  RSS is likely double-counting the postgres
executable as well, which means that the actual additional memory used
per process is probably just a few meg, which is in line with most
folks' experience with PG.

The "free" stats didn't look like a machine under any sort of memory
pressure --- there's zero swap usage, and nearly half of real RAM is
being used for disk cache, which means the kernel can find no better
use for it than caching copies of disk files.  Plus there's still 10G
that's totally free.  Maybe things get worse when the machine's been up
longer, but this sure isn't evidence of trouble.

I'm inclined to think that the problem is not RAM consumption at all but
something else.  What exactly happens when the server "hangs"?

			regards, tom lane