From: Jim C. Nasby <jnasby@pervasive.com>
To: pgsql-performance@postgresql.org
Subject: pg_xlog on data partition with BBU RAID
Date: Fri, 9 Jun 2006 14:41:16 -0500
Message-ID: <20060609194116.GD57289@pervasive.com> (raw)
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.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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: jnasby@pervasive.com
Subject: Re: pg_xlog on data partition with BBU RAID
In-Reply-To: <20060609194116.GD57289@pervasive.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