Re: MusicBrainz postgres performance issues - Mailing list pgsql-performance

From Andres Freund
Subject Re: MusicBrainz postgres performance issues
Date
Msg-id 20150315172048.GG9324@alap3.anarazel.de
Whole thread Raw
In response to Re: MusicBrainz postgres performance issues  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: MusicBrainz postgres performance issues  (Ilya Kosmodemiansky <ilya.kosmodemiansky@postgresql-consulting.com>)
List 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


pgsql-performance by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: MusicBrainz postgres performance issues
Next
From: Ilya Kosmodemiansky
Date:
Subject: Re: MusicBrainz postgres performance issues