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

Re: asynchronous commit feature

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: Decibel! <decibel(at)decibel(dot)org>
Cc: "postgresql performance list" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: asynchronous commit feature
Date: 2007-08-27 21:18:05
Message-ID: b42b73150708271418s363a7de3nc6fbb1ed01178255@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On 8/27/07, Decibel! <decibel(at)decibel(dot)org> wrote:
> On Thu, Aug 23, 2007 at 09:09:00AM -0400, Merlin Moncure wrote:
> > I'm testing the new asynch commit feature on various raid
> > configurations and my early findings is that it reduces the impact of
> > keeping wal and data on the same volume.  I have 10 disks to play
> > with, and am finding that it's faster to do a 10 drive raid 10 rather
> > than 8 drive raid 10 + two drive wal.
> >
> > anybody curious about the results, feel free to drop a line.  I think
> > this will be a popular feature.
>
> With or without a write cache on the RAID controller? I suspect that for
> many systems, a write-caching controller will be very similar in
> performance to async commit.

I usually only work with mid to high end hardware.

The platform I'm testing on is:
10x146gb 15k rpm sas in Dell md1000
2xperc 5/e in active/active (5 drives each controller)
2x146gb 15krpm sas on the backplane perc 5/i (for o/s, wal)

in my experience, even with a high end raid controller moving the wal
offline is helpful in high activity systems, especially during
checkpoints.

merlin

In response to

pgsql-performance by date

Next:From: Kevin GrittnerDate: 2007-08-27 21:56:33
Subject: Re: significant vacuum issues - looking forsuggestions
Previous:From: Decibel!Date: 2007-08-27 21:00:41
Subject: Re: significant vacuum issues - looking for suggestions

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