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

Re: H/W RAID 5 on slower disks versus no raid on faster HDDs

From: David Gilbert <dgilbert(at)velocet(dot)ca>
To: "Hossein S(dot) Zadeh" <hossein(at)bf(dot)rmit(dot)edu(dot)au>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: H/W RAID 5 on slower disks versus no raid on faster HDDs
Date: 2002-11-26 02:36:30
Message-ID: 15842.56878.270786.630651@canoe.velocet.net (view raw or flat)
Thread:
Lists: pgsql-admin
>>>>> "Hossein" == Hossein S Zadeh <hossein(at)bf(dot)rmit(dot)edu(dot)au> writes:

Hossein> On Mon, 2002-11-25 at 23:03, David Gilbert wrote:
>>  I'm on a bit of a mission to stamp out this misconception.  In my
>> testing, all but the most expensive hardware raid controllers are
>> actually slower than FreeBSD's software RAID.  I've done my tests
>> with a variety of controllers with the same data load and the same
>> disks.

Hossein> Hi there, Interesting observation. But I am just curious; is
Hossein> this still valid when you have a DB server with, say, 95+%
Hossein> CPU utilisation??!! (I guess we all know that if one don't
Hossein> get high CPU utilisation on a DB server, either the owner has
Hossein> had too much money, or the DBA has some fine tuning to do).

Typically, the limit on the speed of disk transactions in a modern
system is latency.  The amount of CPU required to perform a RAID 5
calculation is trivial and RAID 1 scheduling (done efficinetly) is
even less demanding on a CPU.

... the latency is the time between when we decide to do the action
and when it is able to be done (in this case).  In the software RAID-5
case, we need to schedule two reads, perform a caluclation when they
return and then schedule two writes.  This all happens within the OS's
decision to write a block and the block actually being written (and
it's why RAID 5 is very slow at writing).

RAID-1 writing is simpler ... the Os needs to schedule two writes
instead of one.

In the hardware case, the OS schedules a write, then it's transferred
to the RAID card ... where the RAID card must then schedule the reads
and writes.

... which is fine if the RAID card has sufficient buffer... but when
things approach saturation of the disk you start to get a number of
effects.

- if a read doesn't occur before the write must be flushed to disk,
  nothing is saved by not committing it immediately.

- The OS has a good handle on what the data represents and is likely
  flushing it fairly optimally.

Think: your primary CPU is 2Ghz (or more) and your main memory is 1G
(or more).  Your moderately expensive RAID card is a 100Mhz RISC chip
with 64M of memory.  How much is this helping?  Not much.

Remember: hardware RAID is simply RAID software running on another
processor.

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert(at)velocet(dot)net             |  equal if and only if they |
|http://daveg.ca                              |   are precisely opposite.  |
=========================================================GLO================

In response to

pgsql-admin by date

Next:From: David GilbertDate: 2002-11-26 02:42:54
Subject: Re: H/W RAID 5 on slower disks versus no raid on faster HDDs
Previous:From: nikolausDate: 2002-11-26 01:08:13
Subject: Re: H/W RAID 5 on slower disks versus no raid on faster HDDs

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