| From: | Jim Nasby <decibel(at)decibel(dot)org> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: shared_buffers documentation |
| Date: | 2010-04-20 17:07:56 |
| Message-ID: | 488CAFD7-C2CA-450F-93BC-69768503755B@decibel.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Apr 16, 2010, at 4:56 PM, Robert Haas wrote:
> From reading this and other threads, I think I generally understand
> that the perils of setting shared_buffers too high: memory is needed
> for other things, like work_mem, a problem which is exacerbated by the
> fact that there is some double buffering going on. Also, if the
> buffer cache gets too large, checkpoints can involve writing out
> enormous amounts of dirty data, which can be bad.
I've also seen large shared buffer settings perform poorly outside of IO issues, presumably due to some kind of internal lock contention. I tried running 8.3 with 24G for a while, but dropped it back down to our default of 8G after noticing some performance problems. Unfortunately I don't remember the exact details, let alone having a repeatable test case.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-04-20 17:09:15 | BETA |
| Previous Message | Kevin Grittner | 2010-04-20 17:07:13 | Re: should I post the patch as committed? |