Skip site navigation (1) Skip section navigation (2)

Re: how big shmmax is good for Postgres...

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Jessica Richard" <rjessil(at)yahoo(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: how big shmmax is good for Postgres...
Date: 2008-07-10 15:37:19
Message-ID: dcc563d10807100837g1dd6a7c8we77f9b6bf59b108e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Some corrections:

On Thu, Jul 10, 2008 at 6:11 AM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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.

In response to

pgsql-performance by date

Next:From: Ow Mun HengDate: 2008-07-11 02:17:00
Subject: Re: Altering a column type - Most efficient way
Previous:From: Alvaro HerreraDate: 2008-07-10 13:57:56
Subject: Re: Altering a column type - Most efficient way

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group