Performance in Intel IOMeter: DataBase Pattern

We traditionally start out by checking the controller’s operation with mixed streams of requests.

This pattern sends a stream of requests to read and write 8KB random-address data blocks. By changing the ratio of reads to writes we can check how well the controller’s driver can sort them out. The results of the controller in WriteBack mode are presented in the table:

Let’s view these numbers as diagrams, which will show the dependence of the controller’s speed on the percentage of write requests for queue depths of 1, 16 and 256 requests. For better readability we divide the arrays into two groups.

Under linear load and the arrays have similar speeds in Random Read mode. When there are more write requests to be processed, the efficiency of lazy writing grows up and the speed of the single drive grows up.

The speed of the RAID0 arrays also grows up depending on the number of disks per array, but it doesn’t scale up exactly proportionally to the number of the disks even in Random Write mode (there’s a smaller difference between the two- and three-disk arrays than between the three- and four-disk ones).

The mirroring arrays (RAID1 and RAID10) seem to alternate the requests between the two disks of the mirror because their performance improves (above that of the JBOD and the two-disc RAID0) at higher percentages of reads. When the writes percentage is high, the alternating algorithm is not efficient as is exampled by the RAID1 whose performance degenerates suddenly at 70-90% of writes.

In theory, the RAID5 performance must improve as there are more writes to be performed. In this case, however, the speed of both RAID5 arrays remains almost the same in all test modes. Moreover, the three- and four-disk RAID5 do not differ between each other much…

The load becomes heavier:

The higher load makes the dependence between the performance of the array and the number of drives in it conspicuous even at 100% reads, but the situation seems illogical at high percentages of writes. There are two distinctly different groups of arrays (1- and 2-disk as opposed to 3- and 4-disk ones) as if their cache policy were different. Can the controller assign different cache quotas for the arrays? This is a logical supposition as the cache buffer can be divided either proportionally to the number of the drives attached to the controller or to the number and type of the arrays. Since the arrays with fewer drives use lazy writing more aggressively, we suppose that we deal with the first case here.

This effect may be actually due to our method of testing RAID controllers. To make sure we complete the tests with the same hard disk drives (and we deliberately select hard drives from the same series and with the same firmware version), we begin to test the controller with arrays made of the maximum number of disks and then disconnect the unnecessary disks (we physically uninstall them from the rack). After a system reboot the controller reads the configuration of the physical drives and arrays and sees only as many drives as we want to have in the array, so it may well increase the quota to arrays of a fewer number of drives.

In real life, however, there is a high probability that the maximum number of drives the controller supports are immediately attached to it (what else would you want to buy this exactly controller for?) and the quotas are assigned depending on this number, irrespective of what arrays you are going to unite the attached drives into. In this case the performance of the arrays may differ from what we’ve got in our tests. Well, we just have to content ourselves that it is virtually impossible to test the controller in each and every operating situation possible.