Databases Reference
In-Depth Information
be a hit in the RAID cache is vanishingly small. Because the RAID cache is so much
smaller, it will almost certainly have been flushed and filled with other data, too.
Either way you look at it, it's a waste of memory to cache reads in the RAID cache.
Caching read-ahead data
If the RAID controller notices sequential requests for data, it might decide to do a
read-ahead read—that is, to prefetch data it predicts will be needed soon. It has to
have somewhere to put the data until it's requested, though. It can use the RAID
cache for this. The performance impact of this can vary widely, and you should
check to ensure it's actually helping. Read-ahead operations might not help if the
database server is doing its own smart read-ahead (as InnoDB does), and it might
interfere with the all-important buffering of synchronous writes.
Caching writes
The RAID controller can buffer writes in its cache and schedule them for a later
time. The advantage to doing this is twofold: first, it can return “success” to the
host system much more quickly than it would be able to if it had to actually perform
the writes on the physical disks, and second, it can accumulate writes and do them
more efficiently.
Internal operations
Some RAID operations are very complex—especially RAID 5 writes, which have
to calculate parity bits that can be used to rebuild data in the event of a failure. The
controller needs to use some memory for this type of internal operation.
This is one reason why RAID 5 can perform poorly on some controllers: it needs
to read a lot of data into the cache for good performance. Some controllers can't
balance caching writes with caching for the RAID 5 parity operations.
In general, the RAID controller's memory is a scarce resource that you should try to
use wisely. Using it for reads is usually a waste, but using it for writes is an important
way to speed up your I/O performance. Many controllers let you choose how to allocate
the memory. For example, you can choose how much of it to use for caching writes
and how much for reads. For RAID 0, RAID 1, and RAID 10, you should probably
allocate 100% of the controller's memory for caching writes. For RAID 5, you should
reserve some of the controller's memory for its internal operations. This is generally
good advice, but it doesn't always apply—different RAID cards require different con-
figurations.
When you're using the RAID cache for write caching, many controllers let you config-
ure how long it's acceptable to delay the writes (one second, five seconds, and so on).
A longer delay means more writes can be grouped together and flushed to the disks
optimally. The downside is that your writes will be more “bursty.” That's not a bad
thing, unless your application happens to make a bunch of write requests just as the
controller's cache fills up, when it's about to be flushed to disk. If there's not enough
room for your application's write requests, it'll have to wait. Keeping the delay shorter
means you'll have more write operations and they'll be less efficient, but it smoothes
