We all know how important hardware RAID controllers are in today’s data storage performance especially when dealing with large data sets. If we look at the trend from now to couple of years back; they really evolved rapidly with lot of useful features and their usage also grown as most of the new servers by default has one or two controllers built-in (one for internal and another one for external storage array or for redundancy).
Few popular RAID controller vendors in the market:
- PERC Controllers from DELL
- Adaptec RAID Controllers
- 3Ware RAID Controllers (now part of LSI)
- LSI RAID Controllers
- Smart Array Controllers from HP
- Intel RAID Controllers
More or less everyone supports all common features and differs in number of ports, protocol support (ISCSI, SATA, SAS, HBA/FB), transfer speed, RAID levels, total disks support, cache size and its management.
Controller Cache – Database Workloads
For database OLTP workloads (IO bound), controller cache plays a crucial role for overall write or read throughput, depending on how the cache is used. Most RAID controllers are equipped with either 128MB or 256 MB or 512MB cache, and newer controllers like HP Smart Array P812 supports 1GB.
Write-back mode improves the writes performance by magnitude as the write request is returned as completed as soon as the data is in the controller cache without actually writing to the disk (that’s why controller needs a BBU, Battery Backup Module so that there is no data loss on power failures)
In case if you enable the read ahead from the controller (sometimes good for OLAP workloads or ETL data warehouse, especially adaptive read ahead due to heavy sequential access); then the same cache is used to store the pre-fetched data that can be satisfied later from the cache without hitting the disk. But in case if the database system does read ahead (like InnoDB), then it is better to turn off read ahead from controller to avoid page trashing.
For some workloads, the controller cache can also cause negative performance if the cache is not properly utilized by the controller.
Missing Cache Management Tools
At present, none of the controllers either supports any cache management tools nor exposes how the cache has been actually used, so that one can adjust the cache according to the workloads for improved performance.
Some of the missing features:
-
A way to flush the data from cache to disks, so that the systems can be taken for offline maintenance. Right now there is no easy way to flush data from cache to disk; other than some of the controllers will indicate through LED whether data is in the cache or not
-
Way to set the cache threshold in time or %, so that it can start flushing to disk once it meets the threshold value. For example; if you notice big spikes from RRD graphs for every few minutes, then one can adjust the threshold to evenly distribute the load.
-
Cache usage statistics (writes data size, read ahead data size etc ), so that workload can be adjusted to yield much better results
-
Splitting of cache between reads and writes either in size or by %; so that they do not overlap and cause performance issues. For example; one prefers to set 20% for read ahead data and 80% for writes. Only HP Smart Array controller supports this feature at present.
As you get more control over the controller cache, the more you can tweak and adjust the workloads to get improved performance. Hopefully one day all vendors will expose more cache management options.
Nice summary; I even sent a requirement once to Dell to allow splitting of read and write cache sizes; but no response yet; even though we use ~2200 DELL systems
Check out the MegaCLI tool that work with Dell Perc 5i/6i and some of the newer Dell HBAs along with the LSI cards.
Userguide here: http://www.lsi.com/DistributionSystem/AssetDocument/80-00156-01_RevH_SAS_SW_UG.pdf (its damn long).
You can control how often the cache flushes to disk, background consistency check throughput, cache read ahead policy (adaptive read ahead = if two blocks get read, cache the next), straight up read one cache the next, read ahead. Or no read ahead. There are many more features to the megacli tool.
[…] Here is a quick link to a blog post that talks about RAID caching for various database workloads. The post also lists some of the popular RAID cards that are being put into use today, as well as some interesting features that the author feels are missing from these current lineup of available RAID cards. Did you enjoy this article? If yes, then subscribe to my RSS Feed […]
Paul, thanks for the Doc; I will check.
Venu,
You can force the cache to be flushed by turning it off for writes, most CLI tools will allow you to flip it to 100% read, which will force it to be flushed within a few seconds.
Regards,
Jeremy
Thanks Jeremy. I will double check and update the post; but not all controllers have that ability.
http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=115&prodSeriesId=33695&prodTypeId=12169&objectID=lpg30009 has some of those missing features (HP Surestore) with cache threshold, and cache minimum retention (how much of the cache to flush), etc. Can also change the ratio of read/write caching (why wouldnt letting the OS cache all reads be more advantageous, leaving the IO ram for buffering writes? Ram in a server is far cheaper AND faster than ram on an IO card – one of my VPS boxes has only 8 gigs for the VMs and 10 gigs cached. Reads are 5x less frequent than writes on that server, easily (mostly LAMP VPS’s).
Someone truly needs to make a chart of which controllers have which features. It’s incredibly hard to get good information out of vendor tech specs pages. 🙁 Anyone want to help start a wikipedia ‘comparison of raid controllers’ page? 🙂
[…] write disks or when you have IO saturation; but it does not matter when you have descent disks or raid controller with write_cache with BBU […]