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

Re: wal_buffers, redux

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: wal_buffers, redux
Date: 2012-03-14 03:18:59
Message-ID: CA+TgmobjYLxLojw2SaDnPX6ch7LtbdrK0QSJ5czsTXiVg8OTCA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Mar 13, 2012 at 6:44 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> 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.
>
> Hmmmm.   Do you have any ability to test on XFS?

It seems I do.

XFS, with fsync = on:
tps = 14746.687499 (including connections establishing)
XFS, with fsync = off:
tps = 25121.876560 (including connections establishing)

No real dramatic difference there, maybe a bit slower.

On further thought, it may be that this is just a simple case of too
many checkpoints.  With fsync=off, we don't have to actually write all
that dirty data back to disk.  I'm going to try cranking up
checkpoint_segments and see what happens.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-03-14 03:41:39
Subject: Re: Command Triggers, patch v11
Previous:From: Daniel FarinaDate: 2012-03-14 02:39:24
Subject: Re: Chronic performance issue with Replication Failover and FSM.

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