public inbox for [email protected]
help / color / mirror / Atom feedFrom: Josh Berkus <[email protected]>
To: [email protected]
Subject: Re: Volunteer to build a configuration tool
Date: Wed, 27 Jun 2007 16:19:45 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Lance,
> I have a PostgreSQL database that runs on a dedicated server. The
> server has 24Gig of memory. What would be the max size I would ever
> want to set the shared_buffers to if I where to relying on the OS for
> disk caching approach? It seems that no matter how big your dedicated
> server is there would be a top limit to the size of shared_buffers.
There's not, actually. Under some circumstances (mainly Solaris 10 + UFS
on AMD) it can actually be beneficial to have s_b be 80% of RAM and bypass
the FS cache entirely. This isn't usually the case, but it's not to be
ruled out.
If you're relying on the FS cache and not using direct I/O, though, you
want to keep at least 50% of memory free for use by the cache. At below
50%, you lose a significant part of the benefit of the cache without
losing the cost of it. Of course, that assumes that your database is
bigger than ram; there isn't much need to have either s_b or the f.s.c. be
more than twice the size of your whole database.
In general, a setting s_b to 25% of RAM on a dedicated machine, and 10%
(with a max of 512MB) on a shared machine, is a nice safe default which
will do OK for most applications.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
view thread (33+ messages)
reply
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: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Volunteer to build a configuration tool
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox