From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Jim C. Nasby <jnasby@pervasive.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: pg_xlog on data partition with BBU RAID
Date: Fri, 09 Jun 2006 15:21:22 -0500
Message-ID: <1149884482.27878.4.camel@state.g2switchworks.com> (raw)
In-Reply-To: <20060609194116.GD57289@pervasive.com>
References: <20060609194116.GD57289@pervasive.com>
On Fri, 2006-06-09 at 14:41, Jim C. Nasby wrote:
> AFAIK, the reason why seperating pg_xlog from the base files provides so
> much performance is because the latency on pg_xlog is critical: a
> transaction can't commit until all of it's log data is written to disk
> via fsync, and if you're trying to fsync frequently on the same drive as
> the data tables are on, you'll have a big problem with the activity on
> the data drives competing with trying to fsync pg_xlog rapidly.
>
> But if you have a raid array with a battery-backed controller, this
> shouldn't be anywhere near as big an issue. The fsync on the log will
> return very quickly thanks to the cache, and the controller is then free
> to batch up writes to pg_xlog. Or at least that's the theory.
>
> Has anyone actually done any testing on this? Specifically, I'm
> wondering if the benefit of adding 2 more drives to a RAID10 outweighs
> whatever penalties there are to having pg_xlog on that RAID10 with all
> the rest of the data.
I tested it WAY back when 7.4 first came out on a machine with BBU, and
it didn't seem to make any difference HOW I set up the hard drives,
RAID-5, 1+0, 1 it was all about the same. With BBU the transactions per
second varied very little. If I recall correctly, it was something like
600 or so tps with pgbench (scaling and num clients was around 20 I
believe) It's been a while.
In the end, that server ran with a pair of 18 Gig drives in a RAID-1 and
was plenty fast for what we used it for. Due to corporate shenanigans
it was still running pgsql 7.2.x at the time. ugh.
I've not got access to a couple of Dell servers I might be able to test
this on... After our security audit maybe.
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: smarlowe@g2switchworks.com, jnasby@pervasive.com
Subject: Re: pg_xlog on data partition with BBU RAID
In-Reply-To: <1149884482.27878.4.camel@state.g2switchworks.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