From: Merlin Moncure <mmoncure@gmail.com>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: Jeff Davis <pgsql@j-davis.com>
Cc: Bucky Jordan <bjordan@lumeta.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: PowerEdge 2950 questions
Date: Thu, 24 Aug 2006 16:03:39 -0400
Message-ID: <b42b73150608241303i65bf25afqeb3e6910a09c128d@mail.gmail.com> (raw)
In-Reply-To: <1156448308.7223.71.camel@state.g2switchworks.com>
References: <78ED28FACE63744386D68D8A9D1CF5D4104ACF@MAIL.corp.lumeta.com>
<1156285374.15743.118.camel@dogma.v10.wvs>
<b42b73150608240621v453e3aeen44f09cd274f9a7@mail.gmail.com>
<1156436690.15743.181.camel@dogma.v10.wvs>
<b42b73150608241157j7076d268h42a57cf3c26a4b34@mail.gmail.com>
<1156448308.7223.71.camel@state.g2switchworks.com>
On 8/24/06, Scott Marlowe <smarlowe@g2switchworks.com> wrote:
> On Thu, 2006-08-24 at 13:57, Merlin Moncure wrote:
> > On 8/24/06, Jeff Davis <pgsql@j-davis.com> wrote:
> > > On Thu, 2006-08-24 at 09:21 -0400, Merlin Moncure wrote:
> > > > On 8/22/06, Jeff Davis <pgsql@j-davis.com> wrote:
> > > > > On Tue, 2006-08-22 at 17:56 -0400, Bucky Jordan wrote:
> > > > it's not the parity, it's the seeking. Raid 5 gives you great
> > > > sequential i/o but random is often not much better than a single
> > > > drive. Actually it's the '1' in raid 10 that plays the biggest role
> > > > in optimizing seeks on an ideal raid controller. Calculating parity
> > > > was boring 20 years ago as it inolves one of the fastest operations in
> > > > computing, namely xor. :)
> > >
> > > Here's the explanation I got: If you do a write on RAID 5 to something
> > > that is not in the RAID controllers cache, it needs to do a read first
> > > in order to properly recalculate the parity for the write.
> >
> > it's worse than that. if you need to read something that is not in
> > the o/s cache, all the disks except for one need to be sent to a
> > physical location in order to get the data.
>
> Ummmm. No. Not in my experience. If you need to read something that's
> significantly larger than your stripe size, then yes, you'd need to do
> that. With typical RAID 5 stripe sizes of 64k to 256k, you could read 8
> to 32 PostgreSQL 8k blocks from a single disk before having to move the
> heads on the next disk to get the next part of data. A RAID 5, being
> read, acts much like a RAID 0 with n-1 disks.
i just don't see raid 5 benchmarks backing that up. i know how it is
supposed to work on paper, but all of the raid 5 systems I work with
deliver lousy seek performance. here is an example from the mysql
folks:
http://peter-zaitsev.livejournal.com/14415.html
and another:
http://storageadvisors.adaptec.com/2005/10/13/raid-5-pining-for-the-fjords/
also, with raid 5 you are squeezed on both ends, too few disks and you
have an efficiency problem. too many disks and you start to get
concerned about mtbf and raid rebuild times.
> It's the writes that kill performance, since you've got to read two
> disks and write two disks for every write, at a minimum. This is why
> small RAID 5 arrays bottleneck so quickly. a 4 disk RAID 4 with two
> writing threads is likely already starting to thrash.
>
> Or did you mean something else by that?
well, that's correct, my point was that a 4 disk raid 1 can deliver
more seeks, not necessarily that it is better. as you say writes
would kill performance. raid 10 seems to be a good compromise. so is
raid 6 possibly, although i dont see a lot performance data on that.
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, smarlowe@g2switchworks.com, pgsql@j-davis.com, bjordan@lumeta.com
Subject: Re: PowerEdge 2950 questions
In-Reply-To: <b42b73150608241303i65bf25afqeb3e6910a09c128d@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