Wednesday, March 28, 2012

RAID 5 beats RAID 10

RAID 5 beats RAID 10
Can I get some feedback on these results? We were having some serious
IO issues according to PerfMon so I really pushed for RAID 10. The
results are not what I expected.
I have 2 identical servers.
Hardware:
PowerEdge 2850
2 dual core dual core Xeon 2800 MHz
4GB RAM
Controller Cards: Perc4/DC (2 arrays), Perc4e/Di (1 array)
PowerVault 220S
Each Array consisted of 6-300 GB drives.
Server 1 = Raid 10
3, 6-disk arrays
Server 2 = Raid 5 (~838 GB each)
3, 6-disk arrays (~1360 GB each)
Test Winner % Faster
SQL Server - Update RAID 5 13
Heavy ETL RAID 5 16
SQLIO - Rand Write RAID 10 40
SQLIO - Rand Read RAID 10 30
SQLIO - Seq Write RAID 5 15
SQLIO - Seq Read RAID 5 Mixed
Disktt - Seq Write RAID 5 18
Disktt - Seq Read RAID 5 2000
Disktt - Rand Read RAID 5 62
Pass Mark - mixed RAID 10 Varies
Pass Mark -
Simulate SQL Server RAID 5 1%
I have much more detail than this if anyone is interested.Are you absolutely absolutely absolutely sure the disk write cache on both
machines was set the same?
RAID 10 will always out perform RAID 5 on read performance in a real
situation because it has 2 copies of the data it can concurrently read. When
writing to disk RAID 5 needs to read as well in order to calculate parity.
There is just so much to doing the comparison...
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials
"Dave" <daveg.01@.gmail.com> wrote in message
news:1146510578.745595.255290@.g10g2000cwb.googlegroups.com...
> RAID 5 beats RAID 10
> Can I get some feedback on these results? We were having some serious
> IO issues according to PerfMon so I really pushed for RAID 10. The
> results are not what I expected.
> I have 2 identical servers.
> Hardware:
> PowerEdge 2850
> 2 dual core dual core Xeon 2800 MHz
> 4GB RAM
> Controller Cards: Perc4/DC (2 arrays), Perc4e/Di (1 array)
> PowerVault 220S
> Each Array consisted of 6-300 GB drives.
> Server 1 = Raid 10
> 3, 6-disk arrays
> Server 2 = Raid 5 (~838 GB each)
> 3, 6-disk arrays (~1360 GB each)
> Test Winner % Faster
> SQL Server - Update RAID 5 13
> Heavy ETL RAID 5 16
> SQLIO - Rand Write RAID 10 40
> SQLIO - Rand Read RAID 10 30
> SQLIO - Seq Write RAID 5 15
> SQLIO - Seq Read RAID 5 Mixed
> Disktt - Seq Write RAID 5 18
> Disktt - Seq Read RAID 5 2000
> Disktt - Rand Read RAID 5 62
> Pass Mark - mixed RAID 10 Varies
> Pass Mark -
> Simulate SQL Server RAID 5 1%
> I have much more detail than this if anyone is interested.
>|||All the arrays have the same settings
Read Cache: Adaptive Read Ahead
Write Cache: Write Back
Cache Policy: Cache I/O|||We almost identical hardware and I'm not satisfied at all with the disk
performance. This is based on a gut feeling working with SQL Server 2000
with the same amount of data I'm working with now on SQL Server 2005 with
better hardware. But my problem has been to estimate what to expect. I'm
therefore very interested in your results and test-methods.
First of all: How did you configure the initial raid-setup in bios? Did you
change any of the default parameters for each raid?
"Dave" <daveg.01@.gmail.com> wrote in message
news:1146510578.745595.255290@.g10g2000cwb.googlegroups.com...
> RAID 5 beats RAID 10
> Can I get some feedback on these results? We were having some serious
> IO issues according to PerfMon so I really pushed for RAID 10. The
> results are not what I expected.
> I have 2 identical servers.
> Hardware:
> PowerEdge 2850
> 2 dual core dual core Xeon 2800 MHz
> 4GB RAM
> Controller Cards: Perc4/DC (2 arrays), Perc4e/Di (1 array)
> PowerVault 220S
> Each Array consisted of 6-300 GB drives.
> Server 1 = Raid 10
> 3, 6-disk arrays
> Server 2 = Raid 5 (~838 GB each)
> 3, 6-disk arrays (~1360 GB each)
> Test Winner % Faster
> SQL Server - Update RAID 5 13
> Heavy ETL RAID 5 16
> SQLIO - Rand Write RAID 10 40
> SQLIO - Rand Read RAID 10 30
> SQLIO - Seq Write RAID 5 15
> SQLIO - Seq Read RAID 5 Mixed
> Disktt - Seq Write RAID 5 18
> Disktt - Seq Read RAID 5 2000
> Disktt - Rand Read RAID 5 62
> Pass Mark - mixed RAID 10 Varies
> Pass Mark -
> Simulate SQL Server RAID 5 1%
> I have much more detail than this if anyone is interested.
>|||Actually, I didn't set it up. The servers were built by our systems
department then handed off to me to install/configure SQL Server and to
test.
If you have any specific questions I would be more than happy to find
out. Please be specific because I don't know much about the Raid
bios settings. Remember it is a PowerEdge 2850 and PowerVault 220S.
I just noticed that we have a failed drive on our RAID 5 array. The
array failed before we conducted this last round of test so the Raid 5
data is inaccurate. I will post new data once it is available.|||This isn't really a comparison of apples to apples. You're taking the same
number of disks instead of the same useable disk space. With the RAID 5 arra
y
you're using you're getting striping over 6 disks (with a penalty for
parity)... with RAID 10 you're effectively striping over only 3 disks. What
you need to compare is:
RAID 5 with 4 disks v.
RAID 10 with 6 disks
where both have the same usable disk space. Then - you should see RAID 10
out perform R5. However, I think I'd also need a bit more details on those
numbers.
Hope this helps,
kt
"Dave" wrote:

> All the arrays have the same settings
> Read Cache: Adaptive Read Ahead
> Write Cache: Write Back
> Cache Policy: Cache I/O
>|||I don't agree. Why would you use a 6 disk Raid 10 when you could use a
6 disk Raid 5 that will out perform it? I think that is apples and
apples. We are talking about the most performance for the money
aren't we?
I just re-ran SQLIO after the Raid 5 rebuild and I got similar results
to what I posted above.
Random Write - Raid 10 big winner
Sequential Write - Raid 5 Winner
Random Read - tie (Raid 10 slight favorite)
Sequential Read - tie (Raid 5 Slight favorite)|||Hey there Dave - I completely see your point actually... but usually what
people do (in most cases) is
(1) Figure out how much disk space they need...
(2) Configure their RAID configuration to match their needs:
RAID 10 usually sacrafices more disks for better redundancy and great
performance
RAID 5 usually sacrafices performance for a lower cost.
What you should also test though - is:
The speed of the R5 array when a disk is damaged (in most systems you lose
all caching)
The speed of a backup/restore scenario
Finally, just realize that you are MUCH more likely to have complete array
failure with R5 as it can only tolerate the loss of one drive. R10 can
tolerate the loss of multiple drives (obviously not an entire mirror
pair/set).
Personally, I always error on the side of redundancy AND performance and R5
is usually not worth it. Also, to be honest, if you're doing nothing but pur
e
disk throughput testing you might not really see your SQL Server perf
issues... I can do more *in* the database (in terms of perf) rather than wit
h
the disk (don't get me wrong though - everything helps!).
As a side note - the transaction is WAY more important (in terms of disk
speeds) than the data portion. I wrote a blog entry on tuning the log here:
http://www.sqlskills.com/blogs/kimb...6-c6a2a0d14a9e. That may give you a few other things to think about.
Finally, for some fun (and some great links too), check out www.baarf.com.
It's a bunch of Oracle experts who are in the "Battle Against Any RAID Five"
.
There are also some good discussions there as to why R5 really "isn't worth
it."
Hope this helps!
kt
"Dave" wrote:

> I don't agree. Why would you use a 6 disk Raid 10 when you could use a
> 6 disk Raid 5 that will out perform it? I think that is apples and
> apples. We are talking about the most performance for the money
> aren't we?
> I just re-ran SQLIO after the Raid 5 rebuild and I got similar results
> to what I posted above.
> Random Write - Raid 10 big winner
> Sequential Write - Raid 5 Winner
> Random Read - tie (Raid 10 slight favorite)
> Sequential Read - tie (Raid 5 Slight favorite)
>|||I don't think you proved the Raid 5 outperformed the Raid 10. In real life
you will almost never get sequential reads from database files. Some OLAP
operations may do that but it will be the exception rather than the rule.
One other thing to consider about Raid 10 is that you can get multiple disk
failures and still be operational. With Raid 5 you can only have 1 and then
the performance is severely degraded when you do.
Andrew J. Kelly SQL MVP
"Dave" <daveg.01@.gmail.com> wrote in message
news:1146768412.080063.215970@.j33g2000cwa.googlegroups.com...
>I don't agree. Why would you use a 6 disk Raid 10 when you could use a
> 6 disk Raid 5 that will out perform it? I think that is apples and
> apples. We are talking about the most performance for the money
> aren't we?
> I just re-ran SQLIO after the Raid 5 rebuild and I got similar results
> to what I posted above.
> Random Write - Raid 10 big winner
> Sequential Write - Raid 5 Winner
> Random Read - tie (Raid 10 slight favorite)
> Sequential Read - tie (Raid 5 Slight favorite)
>|||I understand Raid 10 is better at fault tolerance and all. I was the
one who really pushed for Raid 10. I also understand that my little
test doesn't prove anything.
However the Raid 5 server did beat the Raid 10 server on a heavy ETL
process that involved several reads, writes, aggregations, indexing,
etc. The process took less than 5 hours on Raid 5 and well over 6
hours on Raid 10. That code was the best real world test I could come
up with. I repeated the test while the server was under a load (large
updates, and disk benchmark tools running in background) and Raid 5
still won by 20% or more.
I am still not convinced that "true" Raid 5 can beat "true"
Raid 10. I have read several posts on how Dell does not implement true
Raid 10 on the Perc4 controllers. I have also read posts that claim
that dell documentation is inaccurate. I have forwarded our findings
to Dell for comment and I have still not heard back.
http://docs.us.dell.com/support/edo...32/ch8_perc.htm
If the documentation is accurate and I read it correctly then Dell
really doesn't support true Raid 10.
Is there anyway someone can test Raid 5 vs. Raid 10 using a different
controller card?

No comments:

Post a Comment