From: Merlin Moncure <mmoncure@gmail.com>
To: Decibel! <decibel@decibel.org>
Cc: postgresql performance list <pgsql-performance@postgresql.org>
Subject: Re: asynchronous commit feature
Date: Mon, 27 Aug 2007 17:18:05 -0400
Message-ID: <b42b73150708271418s363a7de3nc6fbb1ed01178255@mail.gmail.com> (raw)
In-Reply-To: <20070827201138.GM54309@nasby.net>
References: <b42b73150708230609m4c48f7eel6aa92db4e1f10b13@mail.gmail.com>
<20070827201138.GM54309@nasby.net>
On 8/27/07, Decibel! <decibel@decibel.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
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: mmoncure@gmail.com, decibel@decibel.org
Subject: Re: asynchronous commit feature
In-Reply-To: <b42b73150708271418s363a7de3nc6fbb1ed01178255@mail.gmail.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