Database Reference
In-Depth Information
much of the penalty associated with writes to RAID groups of disks. But the arrays
assume there will be some quiet time in order to flush the cache; otherwise, there will
be an impact to performance. The calculation for write IOPS is as follows:
Write IOPS = Disk IOPS / RAID Write Penalty
However, this only works when things are going well. If you fill your cache by having
too much write IO on slow spindles, or just from general overloading, your array will
stop caching writes and bypass the cache altogether (go write through). In this case,
you'll get at best the raw performance of the RAID groups. This problem can be made
worse when there is a disk failure and a group of RAID disks needs to be rebuilt.
Depending on the type of disks, this can take many hours and severely impact
performance during the rebuild operation.
Let's take the RAID penalties a bit further and look at an example where we are sizing
for performance. In this example, we will look at the requirements of a SQL data store
that needs to be able to deliver 5,000 IOPS. We will assume that the workload is 70%
read and 30% write, which is typical for some OLTP systems.
First, we need to calculate the effective number of IOPS required. This takes the 5,000
IOPS of a 70/30 read/write workload and adjusts for the RAID penalty as follows:
Required Array IOPS =
(Required IOPS * Read %) + RAID Write Penalty * (Required IOPS * Write %)
Example RAID 5 Required IOPS = (5000 * 70%) + 4 * (5000 * 30%) = 9500
You can see from the example in
Table 6.11
that to achieve 5,000 IOPS for a 70% read-
biased SQL workload, we need 9,500 IOPS at RAID 5 from the array. Now that we
know the required array IOPS, we can calculate the number of disks required to achieve
this performance at each of the RAID levels. To do this, we divide the number of IOPS
by the number of IOPS per disk. RAID penalties have already been taken into
consideration due to the previous calculations.
