Solved!
Go to Solutionare IOPS increased while using the WIL ?
I'm trying to do some calculation on IOPS within a Clariion and the write penalty (2) for RAID1 (4 for RAID5) is clear to me, but what if the LUN is participating in replication ? Wil the write to the Write Intend Log count as an IO as well ?
I can imagine not since the WIL is only a bitmap which is in memory as well. Can somebody please clarify this for me ?
I also know this write penalty is slightly different on DMX, especially with the new enginuity. Does anybody know if this is also the case for the newer FLARE codes ?
And finally something about Clones: again on DMX with the 72 code there's something like Asynchronous Copy On First Access, so the immediate penalty on access is almost gone. Is something like that also introduced on Clariion yet ?
All this should be taken into account when calculating the IOPS and therefor the spindel requirements.
I can imagine not since the WIL is only a bitmap which is in memory as well. Can somebody please clarify this for me ?
I also know this write penalty is slightly different on DMX, especially with the new enginuity. Does anybody know if this is also the case for the newer FLARE codes ?
And finally something about Clones: again on DMX with the 72 code there's something like Asynchronous Copy On First Access, so the immediate penalty on access is almost gone. Is something like that also introduced on Clariion yet ?
All this should be taken into account when calculating the IOPS and therefor the spindel requirements.
492
0
Posted November 27th, 2007 04:00
Hy,
I also can't imagine that the bitmapping process count as an IO... but I don't know.
Another thing to consider for calculation: add the percents of the disk crossings to iops calc.
best regards
Manfred492
0
Posted November 28th, 2007 02:00
That's a good one: counting misalignment as extra IOps ! The problem with this is that you can't tell how much extra IOps there will be, because it depends on the block size. For 4kB blocks the extra IOps will be 12,5% (4kB / 32kB = 1/8).
And if you can't have full stripe writes because of this, worst case it doubles the number of I/Os, because misalignment then generates 2 full stripe writes instead of one..... Worst case of course.492
0
Posted November 28th, 2007 03:00
You are right, but I do not mean the crossings due to misalignment.
If the access pattern of the application is clear why not?492
0
Posted November 28th, 2007 03:00
I'm not sure what you mean.... If everything is aligned and you know the IOps behaviour of your application, IMHO this should be enough to start a calculation. Disk crossings are a natural fenomenon due to the fact that data is spread accross multiple disks and full stripe writes are the writes that determine the number of IOps that will take place. In a misaligned setup however there will be more I/Os taking place than in an aligned setup.
And besides that: a disk crossing by itself is an electronical switch / delay measured in micro seconds and cannot be taken into account in the whole IOps calculation.
So what percentage should I add to my calculation due to disk crossings ? I think zero.492
0
Posted November 28th, 2007 04:00
Even if your LUN is aligned you have disk crossings as you stated normal phenomenon.
You are right it normally suffice if you know the iops and the behavior of your app.
if you doing 4k writes and somebody is spitting you a 2k IO between (can happen everytime, can't?), then you'll have disk crossings -> this is what I mean. (maybe it is anyway wrong..)
I thought being accuratly when doing a calculation:
Here is what i'm thinking.
Application: 1000 IOps 4k random (most of them) 30% writes 70% reads R 1/0
Disk Crossings maximum.(4k/64k=6,25%)
300 writes/sek --> 600 writes/sek to disk + %diskcrossing(6,25) = 637,5
R5 :
--> 1200 writes (parity write cannot cause disk crossing and so->) 600 writes +diskcrossing% = again 637,5 + parity 600 = 1237,5
Maybe it is a big error in reasoning...492
0
Posted November 29th, 2007 03:00
Your I/O capacity is based on the number of spindels of a certain type (10k of 15k) and what your storage can handle is the sum of IOps per spindel.
My problem with your "story" is that you state that a disk crossing is an extra I/O, while in fact IMHO it doesn't matter where this I/O is placed: on the next block, track, or even another disk.
I suppose you could try to measure this and drill down in the number of IOs and do the math. Based on that I would like to believe you, other wise I must say I'd rather stay with the general rule of thumbs about read IOs and write penalties.492
0
Posted November 29th, 2007 03:00
Hy RRR,
First thank you for the interessing discussion.
The Clariion track called "Element Size" measured in Blocks is default 128 =64k.
An earlier Flare version (i think prior Flare 19 ) you had the chance to change the element size to 32k or higher (i think up to 256k...).
best regards
Manfred492
0
Posted November 29th, 2007 03:00
Is a Clariion track 32kB or 64kB ? Does this change with a certain Flare code ? I always thought it was 32kB while for DMX2 it's 32kB and DMX3 64kB.143
0
Posted November 29th, 2007 07:00
Ah yes, you're right. I remember this 128 value (I
haven't touched a Clariion in ages.... being stuck
here with a few DMX's...)
that's a blessing
calle2
133 Posts
578
0
Posted December 7th, 2007 10:00
I couldn¿t help but to notice your interesting conversation and I would like to add my two pence worth to the mix¿
According to my notes from my EXCELLENT EMC CLARiiON performance course by Steve Stead: ¿The Write Intent Log (WIL), will, if used, always be updated when the primary image changes. This imposes the cost of an extra write, and adds additional latency to the host I/O.¿
I hope this helps
Carl