Re: Postgres utils chewing RAM

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

In response to

Responses

Browse pgsql-general by date

  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