Skip site navigation (1) Skip section navigation (2)

Re: wal_buffers, redux

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: wal_buffers, redux
Date: 2012-03-14 02:02:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Mar 14, 2012 at 7:20 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Mar 13, 2012 at 3:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Mar 12, 2012 at 4:45 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>> Rerunning all 4 benchmarks (both 16MB and 32MB wal_buffers on both
>>> machines) with fsync=off (as well as synchronous_commit=off still)
>>> might help clarify things.
>> I reran the 32-client benchmark on the IBM machine with fsync=off and got this:
>> 32MB: tps = 26809.442903 (including connections establishing)
>> 16MB: tps = 26651.320145 (including connections establishing)
>> That's a speedup of nearly a factor of two, so clearly fsync-related
>> stalls are a big problem here, even with wal_buffers cranked up
>> through the ceiling.
> And here's a tps plot with wal_buffers = 16MB, fsync = off.  The
> performance still bounces up and down, so there's obviously some other
> factor contributing to latency spikes

Initialization of WAL file? Do the latency spikes disappear if you start
benchmark after you prepare lots of the recycled WAL files?


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-03-14 02:05:02
Subject: Re: Chronic performance issue with Replication Failover and FSM.
Previous:From: Daniel FarinaDate: 2012-03-14 01:41:48
Subject: Re: Chronic performance issue with Replication Failover and FSM.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group