EVA Partition Alignment
EVA partition alignment has been discussed on a few blogs and forums recently, with no concrete evidence that it is beneficial.
Partition alignment is a well documented best practice that can significantly boost I/O throughput. For a detailed explanation of the topic, see Jimmy May's Slide Deck.
Partition alignment is recommended by several SAN vendors, including EMC and Hitachi, yet HP seems remarkably reticent on the subject. The best they can say is that for recent versions of their firmware, partition alignment "neither enhances nor detracts from sequential I/O". The fact that they have explicitly mentioned sequential I/O and that SQL Server performance on an OLTP database consists of a lot of random I/O means that some testing is needed.
Fortunately, I have just had the opportunity to do this on a brand new EVA8100, with brand new servers, and I had the whole environment to myself!
Configuration
Before I go into details of the tests I want to summarize the configuration:- HP EVA8100 has 2 controllers and 8GB of cache.
- 1 Disk Group consisting of 150x 450GB 15K Disks.
- 1 100GB LUN created and presented to the server. The LUN uses HP's proprietory VRAID1.
- The LUN was partitioned with several different offsets (see below) and formatted with 64K file allocation units.
- The server is an HP Proliant DL585 G5 with 2x 4Gb HBAs.
- Multipath load balancing is set to SQST (Service Queue Shortest Time).
Tests were carried out using SQLIO on a 32GB test file. This file was big enough to ensure that the I/O had to go to disk for a large proportion of the time, rather than getting serviced by the cache.
Sequential and random reads and writes were generated using an increasing number of threads (with 32 outstanding I/Os per thread) to try to reach a saturation point where latency increases without a corresponding increase in IOPS or throughput. This technet article explains the concept very well.
The offsets used in these tests were:
| Offset | Reason |
| Unaligned | The default offset for Windows 2000 and 2003 is 32256 bytes |
| 64K | The most common value used, and recommended by most vendors |
| 128K | From what I have read this appears to be the block size used by the EVA, although I have also read that it uses 4K blocks. I tested this size in case it made a difference. |
| 1MB | The default offset for Windows 2008 |
| 2MB | The EVA appears to use 2MB "chunks" in its redundant storage sets (RSS). It's not much effort to test this size as well. |
Test Results
I started out testing sequential I/Os to check HP's statement. My results proved that they were right, and I won't bore you with the results as a graph with every single line superimposed over each other would be pretty pointless!The interesting tests are on random I/O. I used 8K reads and writes on each offset.
Reads/sec for each permutation of threads and offset
| Threads | Unaligned | 64K | 128K | 1MB | 2MB |
| 1 | 9,245 | 9,404 | 9,365 | 9,472 | 9,183 |
| 2 | 16,710 | 16,978 | 17,040 | 17,069 | 17,073 |
| 4 | 23,003 | 23,429 | 23,469 | 23,359 | 23,387 |
| 8 | 24,675 | 25,176 | 25,055 | 24,854 | 25,183 |
| 16 | 25,128 | 25,623 | 25,635 | 25,697 | 25,460 |
| 32 | 25,083 | 25,788 | 25,701 | 25,671 | 25,678 |
This shows an improvement in read IOPS of between 2% and 2.8%.
Writes/sec for each permutation of threads and offset
| Threads | Unaligned | 64K | 128K | 1MB | 2MB |
| 1 | 16,238 | 16,600 | 16,681 | 16,659 | 16,578 |
| 2 | 16,633 | 16,950 | 17,049 | 17,017 | 16,987 |
| 4 | 17,182 | 17,661 | 17,655 | 17,691 | 17,685 |
| 8 | 17,377 | 17,777 | 17,829 | 17,769 | 17,760 |
| 16 | 17,583 | 17,967 | 17,972 | 17,934 | 17,979 |
| 32 | 17,676 | 18,185 | 18,128 | 18,122 | 18,100 |
Writes also show an improvement of between 2% and 2.8%.
Conclusion
These tests were run several times, the unaligned tests were performed in between each aligned test to check the baseline had not changed, and I had the environment to myself, so I have confidence that these results are accurate and repeatable.The improvement with any offset from 64K upwards is small and it would not be worth changing existing partitions, with all the effort that entails. But if you are building a new environment, or presenting a new LUN to a server, the extra few seconds it takes to perform the EVA partition alignment is probably worth it.
