DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=biNdqOqNLbMTnuoY+edDq6gJ8kgNC++vypfQ1YlVt/c+URjP5uqdlLDeMfKRxy1D8iVfvgLK9dEs8fKv64b51ABxNMplkhGVhFDNXxn2e2w0eqPdU1Sk3vWNUyhlg44AJGMXvkThwX55ZzPf+63u2iBOH812gSMkTdby8g9ak0w=
Message-ID: <1d219a6f050817101729be31a0@mail.gmail.com>
Date: Wed, 17 Aug 2005 13:17:33 -0400
From: Chris Hoover <revoohc@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Tuning Effective Cache Question
In-Reply-To: <1d219a6f05081710146acb9d40@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <1d219a6f05081710146acb9d40@mail.gmail.com>

Sorry, forgot to state that we are still on PG 7.3.4.

On 8/17/05, Chris Hoover <revoohc@gmail.com> wrote:
> I have some questions about tuning my effective_cache_size
>=20
> I have a RHEL 2.1 box running with dual Xeon (2.6 GHz I believe and
> they have HT on).  The box has 8GB memory.  In my postgresql.conf, I
> have set the effective_cache_size =3D 530505 (~4GB).
>=20
> However, I am noticing on this machine, top is telling me that I have
> ~3.5GB in the buff and only 3GB in cached.
>=20
> Here are the exact numbers:
> Mem:  7720040K av, 7714364K used,    5676K free,  314816K shrd, 3737540K =
buff
> Swap: 2096440K av,  119448K used, 1976992K free                 3188192K =
cached
>=20
>=20
> 1.  Is the configuration that linux is running in hurting PostgreSQL in a=
ny way?
>=20
> 2.  Is there a negative impact of the effective_cache_size being
> larger than the actual cached memory?
>=20
> 3.  What effect postive or negative does the buff memory have on PostgreS=
QL.\
>=20
> 4.  What exactly is this buff memory used for?  We have had a time
> trying to find a good explanation of what it means.
>=20
> Overall, this system appears to be running fine.  However, I was taken
> back when I saw the current memory configuration.  We have been
> walking a fine line performance wise, and can quickly become i/o
> starved.  So I want to make sure that I am not pushing the db towards
> the i/o starved side.
>=20
> Thanks for any insight,
>=20
> Chris
>