| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
| Cc: | Robert Kaye <rob(at)musicbrainz(dot)org>, Josh Krupka <jkrupka(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: MusicBrainz postgres performance issues |
| Date: | 2015-03-15 17:20:48 |
| Message-ID: | 20150315172048.GG9324@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 2015-03-15 11:09:34 -0600, Scott Marlowe wrote:
> shared_mem of 12G is almost always too large. I'd drop it down to ~1G or so.
I think that's a outdated wisdom, i.e. not generally true. I've now seen
a significant number of systems where a larger shared_buffers can help
quite massively. The primary case where it can, in my experience, go
bad are write mostly database where every buffer acquiration has to
write out dirty data while holding locks. Especially during relation
extension that's bad. A new enough kernel, a sane filesystem
(i.e. not ext3) and sane checkpoint configuration takes care of most of
the other disadvantages.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ilya Kosmodemiansky | 2015-03-15 17:42:51 | Re: MusicBrainz postgres performance issues |
| Previous Message | Scott Marlowe | 2015-03-15 17:11:55 | Re: MusicBrainz postgres performance issues |