From: Jeff Davis <pgsql@j-davis.com>
To: Michael Stone <mstone+postgres@mathom.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: Vacuums on large busy databases
Date: Thu, 14 Sep 2006 18:44:28 -0700
Message-ID: <1158284668.29889.245.camel@dogma.v10.wvs> (raw)
In-Reply-To: <20060915010429.GP6030@mathom.us>
References: <cone.1158247381.60704.30981.1000@zoraida.natserv.net>
<56FA8838-6DEA-4505-990D-85D5EDA26243@fastcrypt.com>
<cone.1158255415.91768.31944.1000@zoraida.natserv.net>
<470FED70-B3BA-4B6C-A6B1-DFD8882746B2@fastcrypt.com>
<cone.1158265846.124028.75607.5001@35st-server.simplicato.com>
<20060914204220.GL6030@mathom.us>
<cone.1158278679.769031.75607.5001@35st-server.simplicato.com>
<1158281522.29889.200.camel@dogma.v10.wvs>
<20060915010429.GP6030@mathom.us>
On Thu, 2006-09-14 at 21:04 -0400, Michael Stone wrote:
> On Thu, Sep 14, 2006 at 05:52:02PM -0700, Jeff Davis wrote:
> >Any long-running system will have very little "free" memory. Free memory
> >is wasted memory, so the OS finds some use for it.
>
> The important part of the output of "free" in this context isn't how
> much is free, it's how much is cache vs how much is allocated to
> programs. Other os's have other ways of telling the same thing. Neither
> of those numbers generally has much to do with how much shows up in ps
> when large amounts of shared memory are in use.
Right, ps doesn't give you much help. But he didn't tell us about the
process. If a process is using all the buffer cache, and you take away
that memory, it could turn all the reads that previously came from the
buffer cache into disk reads, leading to major slowdown and interference
with the database.
Conversely, if you have a large program running, it may not use much of
it's own memory, and perhaps some rarely-accessed pages could be paged
out in favor of more buffer cache. So even if all your memory is taken
with resident programs, your computer may easily accommodate more
processes by paging out rarely-used process memory.
If he knows a little more about the process than he can make a better
determination. But I don't think it will be much of a problem with 8GB
of physical memory.
Regards,
Jeff Davis
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-performance@postgresql.org
Cc: pgsql@j-davis.com, mstone+postgres@mathom.us
Subject: Re: Vacuums on large busy databases
In-Reply-To: <1158284668.29889.245.camel@dogma.v10.wvs>
* 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