Unsolved
This post is more than 5 years old
15 Posts
0
1034
February 29th, 2008 04:00
RAID-5 performance in striped vs concat meta question ?
Hi folks.
I have a question about RAID-5 performance on the DMX-3.
So, I create a RAID-5 7+1 volume which will have 4 tracks in a each stripe with a stripe being the number of tracks that will be written to on each disk in the RAID-5 group before the array moves onto the next disk.
I'm on DMX3 so my track size is 64KB which means that 256KB of data gets written to each disk in the RAID-5 group before it moves onto the next disk.
-Small random writes
Performance wise, I know that small "Random writes to RAID-5 volumes in particular can generate a background read to read the old data/parity & generate a new one."
-Large sequential writes
I also know that "When the workload is that of large sequential writes to RAID-5 this means that enginuity can calculate parity purely on data being written & the overhead of reading old data/parity is removed. "
& I know that in order to benefit from this optimsiation the sequential writes must be at least a complete RAID-5 stripe set with a stripe set for RAID-5 7+1 on DMX3 being 1792KB calculated by multiplying 7(number of disks) by 256KB(individual disk stripe size).
So here's my actual question....:-)
Would creating a striped meta using the RAID-5 7+1 volumes mentioned above effectively prevent me from ever seeing the write optimisation due to the 2 cylinder stripe size at the meta level ?
My thinking is that in this instance if I had striped metas that the striping at the meta level would only allow 960k/2Cyl of data to be written to each meta member which would invoke a performance penalty as old data is read & then new parity is calculated & then both are written back for each RAID-5 meta member. This due to the meta striping preventing a full RAID-5 stripe set being written.
I have read the other posts here that say 2 levels of striping is good but 3 bad & can appreciate that I could be asking a 'well it depends' type question here
Would the best performing option for large sequential writes using RAID-5 here be to use a Concat Meta ?
Here are the documents I've been using for reference
Symmetrix DMX-3 PRODUCT GUIDE P/N 300-002-197 REV A02
page 5-34
EMC® Symmetrix® DMX-4 950 Product Guide P/N 300-004-997 REV A01
page 198
ORACLE DATABASES ON EMC SYMMETRIX STORAGE SYSTEMS Version 1.0
page 7-17
EMC Engineering white paper Symmetrix DMX Data protection options
Thanks
I have a question about RAID-5 performance on the DMX-3.
So, I create a RAID-5 7+1 volume which will have 4 tracks in a each stripe with a stripe being the number of tracks that will be written to on each disk in the RAID-5 group before the array moves onto the next disk.
I'm on DMX3 so my track size is 64KB which means that 256KB of data gets written to each disk in the RAID-5 group before it moves onto the next disk.
-Small random writes
Performance wise, I know that small "Random writes to RAID-5 volumes in particular can generate a background read to read the old data/parity & generate a new one."
-Large sequential writes
I also know that "When the workload is that of large sequential writes to RAID-5 this means that enginuity can calculate parity purely on data being written & the overhead of reading old data/parity is removed. "
& I know that in order to benefit from this optimsiation the sequential writes must be at least a complete RAID-5 stripe set with a stripe set for RAID-5 7+1 on DMX3 being 1792KB calculated by multiplying 7(number of disks) by 256KB(individual disk stripe size).
So here's my actual question....:-)
Would creating a striped meta using the RAID-5 7+1 volumes mentioned above effectively prevent me from ever seeing the write optimisation due to the 2 cylinder stripe size at the meta level ?
My thinking is that in this instance if I had striped metas that the striping at the meta level would only allow 960k/2Cyl of data to be written to each meta member which would invoke a performance penalty as old data is read & then new parity is calculated & then both are written back for each RAID-5 meta member. This due to the meta striping preventing a full RAID-5 stripe set being written.
I have read the other posts here that say 2 levels of striping is good but 3 bad & can appreciate that I could be asking a 'well it depends' type question here
Would the best performing option for large sequential writes using RAID-5 here be to use a Concat Meta ?
Here are the documents I've been using for reference
Symmetrix DMX-3 PRODUCT GUIDE P/N 300-002-197 REV A02
page 5-34
EMC® Symmetrix® DMX-4 950 Product Guide P/N 300-004-997 REV A01
page 198
ORACLE DATABASES ON EMC SYMMETRIX STORAGE SYSTEMS Version 1.0
page 7-17
EMC Engineering white paper Symmetrix DMX Data protection options
Thanks
No Events found!
v760
15 Posts
0
February 29th, 2008 06:00
I've already read the Thread "Meta stripe size to use with RAID-5 disks"
which is what I meant to say here "I have read the other posts here that say 2 levels of striping is good but 3 bad & can appreciate that I could be asking a 'well it depends' type question here"
But while it's a really useful thread it doesn't discuss whether creating a striped meta using RAID-5 volumes will force numerous background reads during long sequential writes as I mentioned above.
Of course I may just be theorising myself up a dead end here, but I was hoping to dig a little deeper than the previous thread & see what you clever folk had to say
Cheers
xe2sdc
6 Operator
•
2.8K Posts
0
February 29th, 2008 06:00
end here, but I was hoping to dig a little deeper
than the previous thread & see what you clever folk
had to say
Ok .. so let's wait for some clever folk to shade some more light on this topic
-s-
xe2sdc
6 Operator
•
2.8K Posts
0
February 29th, 2008 06:00
JasonBailey
147 Posts
0
March 5th, 2008 04:00
end here, but I was hoping to dig a little deeper
than the previous thread & see what you clever folk
had to say
Talk to your local EMC Account Technical Consultant. They should have access to a SPEED (performance) trained resource who can answer this question for you.