From: Gunnar \"Nick\" Bluth <gunnar.bluth@pro-open.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Craig Ringer <craig@2ndQuadrant.com>
Cc: Aaron Bono <aaron.bono@aranya.com>
Cc: Postgres <pgsql-admin@postgresql.org>
Subject: Re: Postgre Eating Up Too Much RAM
Date: Wed, 14 Nov 2012 07:32:28 +0100
Message-ID: <50A33AFC.1000605@pro-open.de> (raw)
In-Reply-To: <6892.1352863143@sss.pgh.pa.us>
References: <CAHfMse1Z+HGnDJ+2may-7vQgOcogjzuGYASB7yPE2CjAmGyCaQ@mail.gmail.com>
<50A309DA.2040702@2ndQuadrant.com>
<6892.1352863143@sss.pgh.pa.us>
Am 14.11.2012 04:19, schrieb Tom Lane:
> 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.
Keep in mind though that (SysV) SHM is accounted as "cached" in all
Linux tools (I know), thus "free" is never "complete" without "ipcs -m"
+ "ipcs -mu" outputs. However I second Tom here; your machine looks
perfectly healthy.
Note that RSS usage of your sessions can quickly "explode" though (due
to copy on write) if your clients start creating large return sets (and
in the worst case, take a lot of time to "collect" them).
You might consider deploying atop (atoptool.nl), which offers to sum up
all data based on user and/or process name, and will enable you to track
the usage stats to the past. Plus the latest version could already have
a seperate display for SHM usage (at least Gerlof promised me to add it ;-).
Cheers,
--
Gunnar "Nick" Bluth
RHCE/SCLA
Mobil +49 172 8853339
Email: gunnar.bluth@pro-open.de
__________________________________________________________________________
In 1984 mainstream users were choosing VMS over UNIX. Ten years later
they are choosing Windows over UNIX. What part of that message aren't you
getting? - Tom Payne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: gunnar.bluth@pro-open.de, tgl@sss.pgh.pa.us, craig@2ndQuadrant.com, aaron.bono@aranya.com
Subject: Re: Postgre Eating Up Too Much RAM
In-Reply-To: <50A33AFC.1000605@pro-open.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox