DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references;
	b=KwldpZw92fTuSAIW2N2KH6l3LjZNjATwvWDTRAZ4HwK6aPDliL7UeFaEUs+Hmp/dHy
	+rj15KoLySU6Q0kypjK75DZ358VjURaqqQnhnquqvLcZryVGOlGyFwT+SmauuQbYUABA
	7SmE/giun4KuU85RGb1Qyn01+a5LbPoSYs7Co=
Message-ID: <dcc563d10807100837g1dd6a7c8we77f9b6bf59b108e@mail.gmail.com>
Date: Thu, 10 Jul 2008 09:37:19 -0600
From: "Scott Marlowe" <scott.marlowe@gmail.com>
To: "Jessica Richard" <rjessil@yahoo.com>
Subject: Re: how big shmmax is good for Postgres...
Cc: pgsql-performance@postgresql.org
In-Reply-To: <dcc563d10807100511s764b51fahac15fbd2fe932822@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <639285.44246.qm@web56404.mail.re3.yahoo.com>
	<dcc563d10807100423m232f5d0aq44e736c98da1db6e@mail.gmail.com>
	<dcc563d10807100511s764b51fahac15fbd2fe932822@mail.gmail.com>

Some corrections:

On Thu, Jul 10, 2008 at 6:11 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:

SNIP

> If you commonly have 100 transactions doing that at once, then you
> multiply much memory they use times 100 to get total buffer >> SPACE << in use,
> and the rest is likely NEVER going to get used.
>
> In these systems, what seems like a bad idea, lowering the
> buffer_size, might be the exact right call.
>
> For session servers and large transactional systems, it's often best
> to let the OS do the best caching of the most of the data, and have
> enough shared buffers to handle 2-10 times the in memory data set
> size.  This will result in a buffer size of a few hundred megabytes.
>
> The advantage here is that the (NOT OS) DATABASE doesn't have to spend a lot of time
> maintaining a large buffer pool and checkpoints are cheaper.
> The background writer can use spare >> CPU << and I/O cycles to write out
> the now smaller number of dirty pages in shared_memory and the system runs
> faster.

>
> Conversely, when you need large numbers of shared_buffers is when you
> have something like a large social networking site.  A LOT of people
> updating a large data set at the same time likely need way more
> shared_buffers to run well.  A user might be inputing data for several
> minutes or even hours.  The same pages are getting hit over and over
> too.  For this kind of app, you need as much memory as you can afford
> to throw at the problem, and a semi fast large RAID array.  A large
>  >> RAID << cache means your RAID controller / array only have to write, on
> average, as fast as the database commits.

Just minor edits.  If there's anything obviously wrong someone please
let me know.