| From: | Ilya Kosmodemiansky <ilya(dot)kosmodemiansky(at)postgresql-consulting(dot)com> |
|---|---|
| To: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
| Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Markella Skempri <markella_skembri(at)hotmail(dot)com>, desmodemone <desmodemone(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Alexey Vasiliev <leopard_ne(at)inbox(dot)ru> |
| Subject: | Re: Why shared_buffers max is 8GB? |
| Date: | 2014-03-26 16:36:01 |
| Message-ID: | CAG95seVygTpT=ue=e0WLnBn_e4GfeQqkprZ3q5_nHZcAu3Tk2Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Mar 26, 2014 at 5:14 PM, Shaun Thomas <sthomas(at)optionshouse(dot)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 side unless 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(at)postgresql-consulting(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2014-03-27 00:35:11 | Re: Connection pooling - Number of connections |
| Previous Message | Shaun Thomas | 2014-03-26 16:14:33 | Re: Why shared_buffers max is 8GB? |