The LUN IOPS is before any RAID write penalty. It's basically what perfmon will show you.
In a simple world without caching algorithms:
If you do 100 writes to a RAID5 LUN, you will see around 400 IOPS go to the RG.
If you do 100 writes to a RAID10 LUN, you will see around 200 IOPS go to the RG.
The RG IOPS is what actually is hitting the disks.
Also write cache will cause the numbers to be different.
I have some log drives that will spike at 1000 IOPS for a minute, but the RAID group will only write about 100 IOPS. The CLARiiON will gather up a bunch of sequential writes into a bunch of cache pages and write in fewer, larger writes to the disk. (The goal is to save up all of those writes into an entire stripe to minimize penalty)
Also, for random IOPS you might see 500 IOPS at the LUN level, but that data won't be flushed to disk until, the CLARiiON is over its watermark, or when those disks are idle. You might see that data written to disk at a more gradual pace.
I'd also maybe check forced flushes/s for the LUN and % dirty pages for the Storage Processors.
You could be getting some forced flushes which are causing the RG IOPS to be ridiculously high. Or it could just be short periods with a lot of writes.
Is this a Raid5 raid group? SATA or FC? 10k or 15k? How many disks in the RG?
> If you do 100 writes to a RAID5 LUN, you will see around 400 IOPS go to the RG.
This is only true for random I/O. For sequential I/O it's slightly different since the parity will only need to be written to once per full stripe write.
> If you do 100 writes to a RAID5 LUN, you will see around 400 IOPS go to the RG.
This is only true for random I/O. For sequential I/O it's slightly different since the parity will only need to be written to once per full stripe write.
That is why I had a paragraph below it explaining full stripe writes for sequential IO and prefaced it with "without caching algorithms".
I agree, but if people see larges pieces of text, I can imagine that they don't read through the whole thing
I a raid group of 5 disks the write penalty of sequential I/O that was written as a full stripe write, the penalty is 1.25. And: the larger the raid group, the smaller the penalty. But large RG's are bad for rebuilding when a disk fails, since all of those disks will need to be read to recalculate the missing data, so if there's only a few disks the rebuild times are also small.
driskollt1
131 Posts
0
December 16th, 2009 11:00
The LUN IOPS is before any RAID write penalty. It's basically what perfmon will show you.
In a simple world without caching algorithms:
If you do 100 writes to a RAID5 LUN, you will see around 400 IOPS go to the RG.
If you do 100 writes to a RAID10 LUN, you will see around 200 IOPS go to the RG.
The RG IOPS is what actually is hitting the disks.
Also write cache will cause the numbers to be different.
I have some log drives that will spike at 1000 IOPS for a minute, but the RAID group will only write about 100 IOPS. The CLARiiON will gather up a bunch of sequential writes into a bunch of cache pages and write in fewer, larger writes to the disk. (The goal is to save up all of those writes into an entire stripe to minimize penalty)
Also, for random IOPS you might see 500 IOPS at the LUN level, but that data won't be flushed to disk until, the CLARiiON is over its watermark, or when those disks are idle. You might see that data written to disk at a more gradual pace.
driskollt1
131 Posts
0
December 16th, 2009 11:00
I'd also maybe check forced flushes/s for the LUN and % dirty pages for the Storage Processors.
You could be getting some forced flushes which are causing the RG IOPS to be ridiculously high. Or it could just be short periods with a lot of writes.
Is this a Raid5 raid group? SATA or FC? 10k or 15k? How many disks in the RG?
RRR
4 Operator
•
5.7K Posts
1
December 17th, 2009 07:00
> If you do 100 writes to a RAID5 LUN, you will see around 400 IOPS go to the RG.
This is only true for random I/O. For sequential I/O it's slightly different since the parity will only need to be written to once per full stripe write.
driskollt1
131 Posts
0
December 17th, 2009 08:00
That is why I had a paragraph below it explaining full stripe writes for sequential IO and prefaced it with "without caching algorithms".
RRR
4 Operator
•
5.7K Posts
0
December 18th, 2009 06:00
I agree, but if people see larges pieces of text, I can imagine that they don't read through the whole thing
I a raid group of 5 disks the write penalty of sequential I/O that was written as a full stripe write, the penalty is 1.25. And: the larger the raid group, the smaller the penalty. But large RG's are bad for rebuilding when a disk fails, since all of those disks will need to be read to recalculate the missing data, so if there's only a few disks the rebuild times are also small.