When dealing with databases, speed and latency are of the utmost importance. Though there’s a tendency to continuously strive for a higher speeds and lower latencies, we can’t always justify the cost. Things are further complicated as performance on systems degrade over time, requiring more resources to bring them back into the realm of expectations. The reality of this scenario has unfortunately not been retired but there are some things we can do to thwart its impact from a systems level by more efficiently taking advantage of our hardware.

There are a number of topics that could be covered that tie into increasing system performance and doing so with your budget in mind but in this writing we will focus on the following variables in the equation: Operating System Configuration and  the architecture of EqualLogic Storage.

First we need to consider our base system configurations; with a fresh installation of Red Hat Enterprise Linux (in this case version 5 Update 5 or 5.5) you are given a set of default configuration files that come with helpful comments for guideline documentation. While these defaults will offer functionality, as they are meant to, it will require configuration tweaks to provide optimal performance. The engineers in the Dell EqualLogic team have produced a respectable library of whitepapers that offer up best practice system configuration parameters that have been found to be effective in their testing in an array of reference architectures. By leveraging some of this material, one can achieve an increase in performance from an EqualLogic storage array by tuning the operating system.

Next, we need to understand the architecture of EqualLogic storage groups when compared to traditional storage environments. In a traditional SAN (Storage Area Network) you have storage controllers that are directly attached to a number of disk trays and the controllers have access to every disk in the SAN. With EqualLogic there is a more dynamic architecture such that each node has a tray of disks and a controller built into a single chassis and the controllers between multiple chassis communicate and work together to form a single logical entity.  In the traditional SAN architecture each data path would link to a controller that had access to the entire array of direct attached disks and the native device-mapper-multipath mechanism was well suited, but this is no longer the case with our dynamic architecture as there isn’t just one central location of access. The new EqualLogic HIT Kit (Version 1.0.0) was designed to address this and allow the operating system to make efficient use of the unique architecture.

The testing that was performed for the content of this article compares different operating system configuration parameters and focuses on their IOPS (Input/Output Operations Per Second) delta using the Oracle Orion tool to simulate an OLTP database workload against a two node EqualLogic PS6010 storage group. The exact hardware configuration isn’t important as we’re concerned only with the increase in performance due to the modification of different operating system configuration and not the raw number of IOPS our configuration is able to produce. It should be noted that the switch configurations in this architectural design follow the EqualLogic engineering team best practices and were not modified between testing runs. An overview of the general architecture can be seen in the diagram below.

The tests consisted of three configurations. The first configuration, ”Base Line”, is a base installation of Red Hat Enterprise Linux 5.5 using native device-mapper-multipath to offer us the MPIO (Multipath I/O) functionality and the native iSCSI daemon for connectivity to our iSCSI volumes using all defaults where applicable. The second configuration, “Best Practices”, is the exact same as the first configuration with the exception of introducing the EqualLogic engineering team’s best practice findings from whitepaper publications for tuning the iSCSI daemon configurations. Finally, our third configuration, “EQL HITKit”, uses the EqualLogic HIT Kit built in dm-switch driver to supply the MPIO functionality instead of the native device-mapper-multipath and incorporates the eqltune (HITKit utility) iSCSI configuration recommendations. The following graph shows the result of these based on percentage of increase in performance.

In the above graph, we can see that at our base line configuration reached what would be considered the 100% performance mark for a default configuration of the operating system tunable attributes. The results seen from the “Best Practices” configuration show an increase of 30.5% in IOPS over the base line. Finally, the “EQL HITKit” configuration shows an even more impressive jump with 44.9% increase in performance over the base line configuration while running an Oracle Orion OLTP simulation performing 75% read and 25% writes.

While these metrics might not be a universal rule for all workload types across all databases and applications, it certainly can be used as a benchmark when characterizing performance and sizing for your particular database environment. I certainly encourage systems administrators and database administrators alike to take the time to research the EqualLogic HIT Kit on their systems that use EqualLogic arrays to ensure they are truly achieving the most out of their system configurations.

DISCLAIMER: An Oracle RAC configuration with ASM using the EqualLogic HITKit is currently not officially supported by Dell. There are engineering efforts ongoing to provide its availability as a supported configuration, but is unavailable as such at this time.