From: Josh Berkus <josh@agliodbs.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Wrong docs on wal_buffers?
Date: Thu, 06 Jan 2011 10:58:59 -0800
Message-ID: <4D2610F3.8070407@agliodbs.com> (raw)
In-Reply-To: <AANLkTi=YLCEGcwa-9hFYykRgTfUVDhZrwNGo7qaJZnRC@mail.gmail.com>
References: <4D24D7DE.6020507@agliodbs.com>
<AANLkTi=YLCEGcwa-9hFYykRgTfUVDhZrwNGo7qaJZnRC@mail.gmail.com>
> And the risks are rather asymmetric. I don't know of any problem from
> too large a buffer until it starts crowding out shared_buffers, while
> under-sizing leads to the rather drastic performance consequences of
> AdvanceXLInsertBuffer having to wait on the WALWriteLock while holding
> the WALInsertLock,
Yes, performance testing has bourne that out. Increasing wal_buffers to
between 1MB and 16MB has benfitted most test cases (DBT2, pgBench, user
databases) substantially, while an increase has never been shown to be a
penalty. Increases above 16MB didn't seem to help, which is
unsurprising given the size of a WAL segment.
> But I wonder if initdb.c, when selecting the default shared_buffers,
> shouldn't test with wal_buffers = shared_buffers/64 or
> shared_buffers/128, with a lower limit of 8 blocks, and set that as
> the default.
We talked about bumping it to 512kB or 1MB for 9.1. Did that get in?
Do I need to write that patch?
It would be nice to have it default to 16MB out of the gate, but there
we're up against the Linux/FreeBSD SysV memory limits again. When are
those OSes going to modernize?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: josh@agliodbs.com, jeff.janes@gmail.com
Subject: Re: Wrong docs on wal_buffers?
In-Reply-To: <4D2610F3.8070407@agliodbs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox