IOPS Formula

Wow thanks for that, that guy asked the same question as me So to summarise...

To figure out the maximum number of back-end IOPS a RAID Array can produce based on a RW ratio and the number of disks:

IOPS = (n * IOPS_SingleDisk) / (%_Read + (RAID_Penalty * %_WRITE))

Some sites seem to use the formula below in their calculator rather than the one above, which is incorrect.

IOPS = (TOTAL_IOPS * %_Read) + ((TOTAL_IOPS * %_Write) / RAID_Penalty)

To figure out the number of back end IOPS required based on front end IOPS and RW ratio:

IOPS = (TOTAL_IOPS * %_Read) + ((TOTAL_IOPS * %_Write) * RAID_Penalty)

If I've made a mistake anywhere in this please let me know

looks good to me, here is another good document to review. Close to the bottom they will have some examples.

If a host performs 2 random IOps on RAID5, where 1 is a read IO and the other a write (per second), the math is as follows:

In RAID5 each incoming small block random IO needs to replace a data block, but also a new parity has to be calculated, but the parity doesn't have to be calculated on the whole stripe, since we know the parity is an XOR and if we know what changes, we can calculate the new parity. So we read the old data, the old parity, calculate the new parity, write the new parity and the new data, so that makes 4 IO operations.

Total back end IO per second =

1 Read IO

1 Write IO, which has a write penalty of 4, so this invokes 4 back end IOs

So it's 1 + 4 = 5 IOs per second

This is easy to understand, right?

So the math is:

Total amount of back end IOps = (TOTAL_IOPS * %_Read)   +   ((TOTAL_IOPS * %_Write) * RAID_Penalty)

This is for small block random IO!

For sequential write IO no data has to be read first and only full stripes will be written, so the write penalty is much smaller (in a 4+1 RAID5 this will be 1.25 instead of 4 (5 writes instead of 4, so 5/4) and you can see that for sequential write workloads RAID5 is much better than RAID10 which always has a write penalty of 2. Even RAID6 will outperform RAID10, since a 4+2 RAID Group will have a write penalty of 1.5 for sequential write workloads (RAID10 is always 2).

Hey,

Can you just expand on the maths for RAID5 sequential write IO penalty? I'm not sure how you get to 1.25.

I understand the normal RAID5 penalty of 4 as below, if you could make a similar comparison for the 1.25 it would be great.

RAID5 Write Penalty

1 read data

1 read parity

1 write data

1 write parity

Cheers.

Sure. Since you're writing a full stripe (sequential write do that), you'll be writing to each of the disks in that stripe, but since in RAID5 you only have 1 drive less for data and you also need to write the parity, you end up writing to 1 disk extra. So for a RAID5 (4+1) you are writing to 4 data disks and 1 parity dis, so 5 IOs in total when the data only occupies 4 of that, so you have a 25% overhead. For 8+1 the overhead is only 12.5%.

Ok, I think I understand.

1. A RAID5 write penalty of 4 assumes assumes the 'write' is modifying just one sector, hence the number of disks in the array are irrelevant. And I say modifying since there is the initial read which counts towards the penalty.

2. The sequential write calculation assumes the write to disk is done without first reading the sector? And since it's a sequential write and it's striping to all the disks the number of disks in the array do matter.

1. Not just 1 sector, but a "small block". This can be up to 64 kB by default, since 64 kB is the smallest (default) block size on 1 disk in a stripe.
2. yes

Just to note that if you write 1 block (512 bytes) the array will read-read-write-write that 1 block, it will not have to do a whole 64KB.

Yes, the stripe element size is 64KB, but we work on blocks of 512bytes,

We are great for transactional activity and that's typically 4KB and 8KB block size, so the backend disk reads and writes for random workloads will be 4KB and 8KB for those random I/O's.

We can coalesce writes when destaging from write cache to reduce the I/O's to the disk for LBA adjoining I/O's in logical space, or destaging random writes going to newly mapped thin lun space - or we might pre-fetch more data in reads, so an 8KB read to a LUN might show up and a 32KB read at the disk -- depends on workload characteristics and what else is going on that might be pushing cache as to what read sizes we might issue -- more so with VNX2 as it's more self adapting to workloads than previous generation VNX's are.

Regards,

~Keith