|
Home > Archive > Data Storage > June 2004 > RAID5 vs RAID10 speed benchmark?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
RAID5 vs RAID10 speed benchmark?
|
|
| - C - 2004-05-30, 11:11 am |
| Has anyone do a benchmark of RAID5 vs RAID10? I am looking for large
sequential reads and writes... Thanks in advance...
Clayton
| |
| Ali-Reza Anghaie 2004-05-30, 11:11 am |
| - C - <junky@ctny.org> wrote:
> Has anyone do a benchmark of RAID5 vs RAID10? I am looking for large
> sequential reads and writes... Thanks in advance...
That's not something that'd be independant of the hardware, drivers,
OS/filesystem, number of disks in the volumes, etc.
-Ali
--
OpenPGP Key: 030E44E6
--
Was I helpful?: http://svcs.affero.net/rm.php?r=packetknife
--
After all, there is but one race - humanity. -- George Moore
| |
| Ron Reaugh 2004-05-30, 11:11 am |
|
"- C -" <junky@ctny.org> wrote in message
news:7eQtc.29236$zO3.27903@newsread2.news.atl.earthlink.net...
> Has anyone do a benchmark of RAID5 vs RAID10? I am looking for large
> sequential reads and writes... Thanks in advance...
You need to provide more information. Let's say one has a RAID 5 array
using N disks and an equivalent overall storage sized RAID 10 array using
2x(N-1) disks. That's apples vs apples. Then if both are well implemented,
the RAID 10 will always be faster in both single queued sequential reading
and single queued sequential writing than the RAID 5. The reading might
only be imperceptibly faster but the writing would be significantly faster.
Non-single queued I/O whether sequential or small record random provides
even a greater advantage to the RAID 10 in most cases.
| |
| Ron Reaugh 2004-05-30, 11:11 am |
| One could also claim that a real apples vs apples comparison would be the
same number of drives in a RAID 5 array vs that same number of drivers in
RAID 10. Then the balance swings towards the RAID 5 performance wise.
"Ron Reaugh" <ron-reaugh@att.net> wrote in message
news:Atauc.8952$_k3.206269@bgtnsc05-news.ops.worldnet.att.net...
>
> "- C -" <junky@ctny.org> wrote in message
> news:7eQtc.29236$zO3.27903@newsread2.news.atl.earthlink.net...
>
> You need to provide more information. Let's say one has a RAID 5 array
> using N disks and an equivalent overall storage sized RAID 10 array using
> 2x(N-1) disks. That's apples vs apples. Then if both are well
implemented,
> the RAID 10 will always be faster in both single queued sequential reading
> and single queued sequential writing than the RAID 5. The reading might
> only be imperceptibly faster but the writing would be significantly
faster.
> Non-single queued I/O whether sequential or small record random provides
> even a greater advantage to the RAID 10 in most cases.
>
>
| |
| Robert Wessel 2004-05-30, 4:57 pm |
| "Ron Reaugh" <ron-reaugh@att.net> wrote in message news:<5Rduc.9511$_k3.223010@bgtnsc05-news.ops.worldnet.att.net>...
> One could also claim that a real apples vs apples comparison would be the
> same number of drives in a RAID 5 array vs that same number of drivers in
> RAID 10. Then the balance swings towards the RAID 5 performance wise.
True for read performance, but not for write performance, where RAID5
continues to get clobbered by the required read-modify-write cycles
for each update.
And please don't top-post.
| |
| Ron Reaugh 2004-05-31, 5:48 pm |
|
"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:bea2590e.0405300943.22402c2a@posting.google.com...
> "Ron Reaugh" <ron-reaugh@att.net> wrote in message
news:<5Rduc.9511$_k3.223010@bgtnsc05-news.ops.worldnet.att.net>...
the[vbcol=seagreen]
in[vbcol=seagreen]
>
>
> True for read performance, but not for write performance, where RAID5
> continues to get clobbered by the required read-modify-write cycles
> for each update.
Not so much when the number of drives is that much different. RAID 5 has a
write performance hit but not necessarily a crippling one. There are also
fancier implementations of RAID 5 where the writes are held pending in a
small RAID 10 array(sub part) and during slow periods written to the full
RAID 5 array.
> And please don't top-post.
Except where appropriate which in this case responding to my own post it was
so appropriate.
| |
| Robert Wessel 2004-06-02, 8:00 am |
| "Ron Reaugh" <ron-reaugh@att.net> wrote in message news:<LeNuc.104019$hH.1832083@bgtnsc04-news.ops.worldnet.att.net>...
> "Robert Wessel" <robertwessel2@yahoo.com> wrote in message
> news:bea2590e.0405300943.22402c2a@posting.google.com...
> news:<5Rduc.9511$_k3.223010@bgtnsc05-news.ops.worldnet.att.net>...
> the
> in
>
> Not so much when the number of drives is that much different.
Errr...? The item under discussion is when the number of drives is
equal.
> RAID 5 has a
> write performance hit but not necessarily a crippling one.
In almost all cases, the RAID5 write will require more work (three or
four I/Os rather than two), compared to RAID1(0). You can get three
on a simple update if the data block happens to be cached. In the
(unusual) case where an entire set of stripes is being overwritten,
the write overhead can actually be lower for RAID5. It's a question
of write load and latency requirements. Increased read performance
may free up more (potential) I/Os for use in write operations. Below
some relative level (of writes vs. reads), this may allow write
performance (throughput) to increase as well. How latency is measured
in your system is important as well - in the RAID5 cases the latency
of completing the write to disk will usually be higher (especially at
low write loads), even when throughput increases. If you measure
latency only to the write to NVRAM, the difference can be minimal.
The ratio of reads to writes is quite environment dependant. In file
service applications reads are often quite popular, while in
transactional (eg. database) systems, writes can be the dominant
workload.
> There are also
> fancier implementations of RAID 5 where the writes are held pending in a
> small RAID 10 array(sub part) and during slow periods written to the full
> RAID 5 array.
Which is then no longer a RAID5 system. And which does not improve
sustained performance.
| |
| Bill Todd 2004-06-02, 8:00 am |
|
"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:bea2590e.0406012320.12bf1be8@posting.google.com...
> "Ron Reaugh" <ron-reaugh@att.net> wrote in message
news:<LeNuc.104019$hH.1832083@bgtnsc04-news.ops.worldnet.att.net>...
....
full[vbcol=seagreen]
>
>
> Which is then no longer a RAID5 system.
Indeed. I think the name for this HP innovation is 'AutoRAID'; John Wilkes'
group there published some papers on it in the 1990s. It's actually more
sophisticated than a simple RAID-10 array acting like a stable write-back
cache in front of the main RAID-5 array: the two arrays share the same
disks, and their relative capacities may even vary dynamically according to
space availability.
And which does not improve
> sustained performance.
Well, it can (in much the same manner as a large, stable write-back cache
can), if the updates have either physical locality (in which case entire
RAID-5 stripe updates may accumulate in the RAID-1 section and be propagated
to the RAID-5 section as full-stripe writes after the activity moves
elsewhere) or temporal locality (in which case repeated updates to the same
data occur in the RAID-1 section and, again, are only propagated to the
RAID-5 section once, after things calm down in that area).
- bill
| |
| Robert Wessel 2004-06-03, 12:00 am |
| "Bill Todd" <billtodd@metrocast.net> wrote in message news:<6KidnSc5A94rESDdRVn-ug@metrocast.net>...
>
> And which does not improve
>
> Well, it can (in much the same manner as a large, stable write-back cache
> can), if the updates have either physical locality (in which case entire
> RAID-5 stripe updates may accumulate in the RAID-1 section and be propagated
> to the RAID-5 section as full-stripe writes after the activity moves
> elsewhere) or temporal locality (in which case repeated updates to the same
> data occur in the RAID-1 section and, again, are only propagated to the
> RAID-5 section once, after things calm down in that area).
That's true, although I expect it's a net gain (in sustained
performance) only for fairly rare workload. For bursty workloads
(where you can do the extra work in an idle period), sure, but for
sustained workloads you're going to have to merge a lot of I/Os to
make up for the extra copy that needs to be done.
| |
| Bill Todd 2004-06-03, 12:00 am |
|
"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:bea2590e.0406021421.4b10fc3f@posting.google.com...
> "Bill Todd" <billtodd@metrocast.net> wrote in message
news:<6KidnSc5A94rESDdRVn-ug@metrocast.net>...
cache[vbcol=seagreen]
propagated[vbcol=seagreen]
same[vbcol=seagreen]
>
>
> That's true, although I expect it's a net gain (in sustained
> performance) only for fairly rare workload. For bursty workloads
> (where you can do the extra work in an idle period), sure, but for
> sustained workloads you're going to have to merge a lot of I/Os to
> make up for the extra copy that needs to be done.
They may be smart enough to avoid a copy: if you lay out the RAID-10
material suavely (leaving an unused parity block in each copy's stripe,
since space efficiency is not paramount for the temporary mirrored part of
the storage) and have an explicit per-stripe map (which you probably want
anyway if you're going to allow the division between RAID-10 and RAID-5
space to vary dynamically), you can just leave one copy of the data in place
and only write the parity when you convert it to RAID-5.
Assuming that none of the RAID-10 data is still cached when the conversion
is performed, this results in N reads and one write, rather than the N reads
and N+1 writes a copy would require (this can be further optimized by
creating parity in memory as each RAID-10 disk segment is evicted from the
cache, avoiding the reads at the cost of a single chunk of cache which
itself could be staged to disk - using the 'spare' disk in the RAID-10
stripe - if space got tight; you'd have to model this to decide exactly what
strategy was best). The stripe map likely is maintained in stable RAM and
updated on disk only occasionally: these aren't low-end arrays. And
conversion doesn't necessarily occur that often: the only reason you *ever*
need to move data from RAID-10 to RAID-5 storage is because you're getting
tight on overall space and need the resulting near-factor-of-2 compression -
and for many update-intensive workloads the net accumulation of data is
relatively slow (if the workload is not update-intensive, you might be
better off just using vanilla-flavored RAID-5 anyway, fronted by a stable
cache if small-chunk extension of existing data is common to consolidate it
into larger writes).
- bill
| |
| Robert Wessel 2004-06-03, 2:56 am |
| "Bill Todd" <billtodd@metrocast.net> wrote in message news:<n7adnY-V4ow08SPd4p2dnA@metrocast.net>...
> They may be smart enough to avoid a copy: if you lay out the RAID-10
> material suavely (leaving an unused parity block in each copy's stripe,
> since space efficiency is not paramount for the temporary mirrored part of
> the storage) and have an explicit per-stripe map (which you probably want
> anyway if you're going to allow the division between RAID-10 and RAID-5
> space to vary dynamically), you can just leave one copy of the data in place
> and only write the parity when you convert it to RAID-5.
>
> Assuming that none of the RAID-10 data is still cached when the conversion
> is performed, this results in N reads and one write, rather than the N reads
> and N+1 writes a copy would require (this can be further optimized by
> creating parity in memory as each RAID-10 disk segment is evicted from the
> cache, avoiding the reads at the cost of a single chunk of cache which
> itself could be staged to disk - using the 'spare' disk in the RAID-10
> stripe - if space got tight; you'd have to model this to decide exactly what
> strategy was best). The stripe map likely is maintained in stable RAM and
> updated on disk only occasionally: these aren't low-end arrays. And
> conversion doesn't necessarily occur that often: the only reason you *ever*
> need to move data from RAID-10 to RAID-5 storage is because you're getting
> tight on overall space and need the resulting near-factor-of-2 compression -
> and for many update-intensive workloads the net accumulation of data is
> relatively slow (if the workload is not update-intensive, you might be
> better off just using vanilla-flavored RAID-5 anyway, fronted by a stable
> cache if small-chunk extension of existing data is common to consolidate it
> into larger writes).
While that neatly avoids much of the work in the RAID10->RAID5
conversion, Aren't you screwed when you need to go the other way?
Unless you save that for a out-of-line process as well, presumably
driven by some accumulated usage statistics (stripe X gets heavy
updates, migrate it to RAID10).
Stripe level HSM, IOW?
| |
| Bill Todd 2004-06-03, 11:00 am |
|
"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:bea2590e.0406022207.6696e113@posting.google.com...
....
> While that neatly avoids much of the work in the RAID10->RAID5
> conversion, Aren't you screwed when you need to go the other way?
> Unless you save that for a out-of-line process as well, presumably
> driven by some accumulated usage statistics (stripe X gets heavy
> updates, migrate it to RAID10).
My (now somewhat vague) recollection is that they maintain usage stats on
the stripes - that's how they determine what to move to RAID-5 when space
starts to get tight. And there's at least somewhat less movement in the
reverse direction: typical usage tends to be create, use heavily, use
lightly, then delete (and for that matter update-in-place operations are
themselves usually the exception rather than the rule, so perhaps the *most*
typical usage - save for actively-updated databases - is create, then read
one or more times, then delete).
>
> Stripe level HSM, IOW?
Yup.
- bill
| |
| perfnerd 2004-06-03, 5:02 pm |
| robertwessel2@yahoo.com (Robert Wessel) wrote in message news:<bea2590e.0406022207.6696e113@posting.google.com>...
> While that neatly avoids much of the work in the RAID10->RAID5
> conversion, Aren't you screwed when you need to go the other way?
> Unless you save that for a out-of-line process as well, presumably
> driven by some accumulated usage statistics (stripe X gets heavy
> updates, migrate it to RAID10).
You don't migrate from RAID5 to RAID10. The read performance for
RAID5 and RAID10 is similar since the data is automatically striped.
So, there is no need to migrate for read performance. Any time a
block gets written, you just write it in RAID10, and let the migration
algorithms handle the movement back to RAID5.
| |
| Robert Wessel 2004-06-05, 12:01 am |
| perfnerd@yahoo.com (perfnerd) wrote in message news:<94d3aca5.0406031138.1621ba8c@posting.google.com>...
> robertwessel2@yahoo.com (Robert Wessel) wrote in message news:<bea2590e.0406022207.6696e113@posting.google.com>...
>
>
> You don't migrate from RAID5 to RAID10. The read performance for
> RAID5 and RAID10 is similar since the data is automatically striped.
> So, there is no need to migrate for read performance. Any time a
> block gets written, you just write it in RAID10, and let the migration
> algorithms handle the movement back to RAID5.
Bill and I were discussing a slightly different arrangement, where
stripes are migrated between RAID5 and RAID10 configurations as
appropriate. The earlier discussion involved a separate RAID10 area
where updates were queued until they could be migrated to main RAID5
area, presumably during a less busy time.
| |
| perfnerd 2004-06-05, 11:58 pm |
| robertwessel2@yahoo.com (Robert Wessel) wrote in message news:<bea2590e.0406041453.637c31d6@posting.google.com>...
> perfnerd@yahoo.com (perfnerd) wrote in message news:<94d3aca5.0406031138.1621ba8c@posting.google.com>...
>
>
>
> Bill and I were discussing a slightly different arrangement, where
> stripes are migrated between RAID5 and RAID10 configurations as
> appropriate. The earlier discussion involved a separate RAID10 area
> where updates were queued until they could be migrated to main RAID5
> area, presumably during a less busy time.
That was my point. When data is written, you write in in RAID10. As
the data ages and there is pressure on the disk usage then you start
migrating from RAID10 to RAID5. You do it during spare cycles. Once
in RAID5 there is no need to from RAID5 to RAID10, read performance
should be the same or better in RAID5 as the data is striped over more
spindles in RAID5.
If an existing block is re-written, you write it in RAID10 and mark
the old block as out-of-date. The invalid block is still used for
data recovery purposes, just not data access. Then you let a
housekeeping process either convert the remaining blocks in the RAID5
checksum block back to RAID10, recalculate the remaing blocks without
the updated data, or reincorporate the new block into the RAID5
checksum block. Pick your rule, or come up with heuristics to choose
one. Scheduling a conversion to RAID10 for the remaining blocks is
probably simplest as you can then let the 10to5 migration process
handle the decision of when to migrate back to RAID5.
| |
| Jesper Monsted 2004-06-26, 2:26 pm |
| robertwessel2@yahoo.com (Robert Wessel) wrote in
news:bea2590e.0405300943.22402c2a@posting.google.com:
> True for read performance, but not for write performance, where RAID5
> continues to get clobbered by the required read-modify-write cycles
> for each update.
Clariion tries to do full stripe writes by leaving the data in (mirrored)
cache. It'll even read whatever's missing to make a full write if that's
easier than the typical read/read/write/write option.
--
/Jesper Monsted
|
|
|
|
|