IOPS

(essay with questions and unanswered)

When I decided to check the performance of the new raid and the 72 disks attached to it, it seemed to me that I knew everything about iops. Now I understand that I do not understand anything.

So, IOPS = i / o (operations) per second. The number of I / O operations per second.
')
Measuring IOPS is very easy - just run almost any performance monitor. perfmon in Windows, atop in Linux. How many times a specific disk managed to respond in a second to “write” / “read” requests, as many IOPS'ov.

But when they say “iops”, they usually mean not the current indicator, but the maximum one that is capable of issuing [disk | raid | shelf].

And here we are waiting for the greatest surprise.

I will not be unfounded, here are the results of measurement.

 write iops = 13200, write speed = 550Mb / s
 write iops = 324, write speed = 1.2Mb / s

This is the same drive. The same amount of data. What is changing, from where this stunning difference of almost two orders of magnitude?

This difference is in the order of execution of requests. The first is linear recording. The second is arbitrary, in blocks of 4k. Strictly recorded the same amount of data, but in a different order.

... And this result would have looked more logical if it were a single hard drive. But it is RAID60 on 22 disks!

I change one parameter in the raid properties (slice size) - and I get completely different numbers for a random entry:

 write iops = 4020 write speed = 16Mb / s

Of course, this is not at all the supersonic speeds of linear operations, but the difference between 320 and 4000 iops is TOO great to ignore.

... I slightly change the conditions of the test (block size) and one version of the raid falls down, and the second explodes up ...

So what is an IOPS? And how can we, at least approximately, estimate the performance of the disk subsystem?

We can say "it is necessary to consider the task." What task? Can you predict the size of the data blocks that your (the one you know best of all) sql server decides to write after the next commit? Or another program you administer: can you say what blocks it will write / read?

And then, without knowing this information, we are confronted with parameters that fundamentally determine the performance of a RAID: the number of disks in mirror and the number of disks in redundant arrays, the size of the strip ...

I have a feeling that among all areas of the "computer device", the performance in the "queries" is the least experienced. Or, if tried, then carefully concealed ...