Date: Sun, 15 Mar 2015 18:20:48 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Robert Kaye <rob@musicbrainz.org>, Josh Krupka <jkrupka@gmail.com>,
 PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: MusicBrainz postgres performance issues
Message-ID: <20150315172048.GG9324@alap3.anarazel.de>
References: <B008F2EE-45D7-4535-9163-56A8CDCA553C@musicbrainz.org>
 <CAB6McgXxZdD6yuYRLg4tgDdhqzXKLs63aV+S_nOfZ9arSXUAhA@mail.gmail.com>
 <9E71CCBE-4CDF-482E-878D-6C16027B6283@musicbrainz.org>
 <20150315135022.GC19792@alap3.anarazel.de>
 <CAOR=d=0YwcnVi3kGD21W7jYjE7DcWjp0v0GjncH-c2-oJEP5Rw@mail.gmail.com>
 <CAOR=d=1Axcbj2VcUO=5tM1nv6RjuA0D+av5+Mt7RTztgTxaMnA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAOR=d=1Axcbj2VcUO=5tM1nv6RjuA0D+av5+Mt7RTztgTxaMnA@mail.gmail.com>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance