From: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
---|---|
To: | "Steve Lane" <slane(at)fmpro(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgres utils chewing RAM |
Date: | 2002-04-29 05:53:58 |
Message-ID: | 20020429015358.282e99dc.nconway@klamath.dyndns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 29 Apr 2002 00:35:38 -0500
"Steve Lane" <slane(at)fmpro(dot)com> wrote:
> I traced through the nightly scripts and found that two things seem to
> account for the memory loss -- vacuuming the databases, and backing them up.
> I restarted to free all my RAM back up and tried just those operations. Sure
> enough, after a vacuum verbose analyze (on about thirty tables totaling
> probably less than 50 MB of data), free memory dropped by 130MB. Backing up
> everything on the server took another 110MB. And this memory never gets
> returned.
AFAICS, there's nothing wrong here. Linux, like any modern OS, will use
free RAM to cache I/O. Apparently, when these database maintainence/
backup utilities are executed, a lot of I/O is generated, and Linux
decides to use some of the spare RAM to cache it. The "free RAM"
number is pretty useless in this regard.
As for returning this memory, Linux should return it if any
applications actually need it.
If you're concerned, run "vmstat 1". If you see any paging under
normal load, you've got a problem -- look into upgrading your
kernel, you might have an early 2.4 kernel with a defective
VM. If you don't see any paging, you're fine -- don't worry
about it.
Cheers,
Neil
--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC
From | Date | Subject | |
---|---|---|---|
Next Message | Jack Bates | 2002-04-29 06:30:58 | CVS tag for 7.2.1? |
Previous Message | Tom Lane | 2002-04-29 05:53:01 | Re: Postgres utils chewing RAM |