Re: Why shared_buffers max is 8GB? - Mailing list pgsql-performance

From Ilya Kosmodemiansky
Subject Re: Why shared_buffers max is 8GB?
Date
Msg-id CAG95seVygTpT=ue=e0WLnBn_e4GfeQqkprZ3q5_nHZcAu3Tk2Q@mail.gmail.com
Whole thread Raw
In response to Re: Why shared_buffers max is 8GB?  (Shaun Thomas <sthomas@optionshouse.com>)
List pgsql-performance
On Wed, Mar 26, 2014 at 5:14 PM, Shaun Thomas <sthomas@optionshouse.com> wrote:
> * Checkpoints must commit dirty shared buffers to disk. The larger this is, the more risk you have when checkpoints
come,up to and including an unresponsive database. Writing to disks isn't free, and sadly this is still on the slower
sideunless all of your storage is SSD-based. You don't want to set this too much higher than your disk write cache. 

We use on some heavy working machines 48GB of shared buffers (and
sometimes more - depends on amount of RAM). Of course that works only
with good enough hardware raid with large bbu, well tuned linux (dirty
bytes appropriate to raid cache size etc) and aggressively tuned both
checkpoints and background writer:

 bgwriter_delay          | 10
 bgwriter_lru_maxpages   | 1000
 bgwriter_lru_multiplier | 10
checkpoint_completion_target | 0.9
 checkpoint_segments          | 300
 checkpoint_timeout           | 3600

and it really makes sense


--
Ilya Kosmodemiansky,

PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
ik@postgresql-consulting.com


pgsql-performance by date:

Previous
From: Shaun Thomas
Date:
Subject: Re: Why shared_buffers max is 8GB?
Next
From: Josh Berkus
Date:
Subject: Re: Connection pooling - Number of connections