From: Scott Marlowe <scott.marlowe@gmail.com>
To: Jessica Richard <rjessil@yahoo.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: how big shmmax is good for Postgres...
Date: Thu, 10 Jul 2008 09:37:19 -0600
Message-ID: <dcc563d10807100837g1dd6a7c8we77f9b6bf59b108e@mail.gmail.com> (raw)
In-Reply-To: <dcc563d10807100511s764b51fahac15fbd2fe932822@mail.gmail.com>
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.
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: scott.marlowe@gmail.com, rjessil@yahoo.com
Subject: Re: how big shmmax is good for Postgres...
In-Reply-To: <dcc563d10807100837g1dd6a7c8we77f9b6bf59b108e@mail.gmail.com>
* 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