SQL Server Power Search - Get More Relevant Results

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:


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:

OffsetReason
UnalignedThe default offset for Windows 2000 and 2003 is 32256 bytes
64KThe most common value used, and recommended by most vendors
128KFrom 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.
1MBThe default offset for Windows 2008
2MBThe 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

ThreadsUnaligned64K128K1MB2MB
19,2459,4049,3659,4729,183
216,71016,97817,04017,06917,073
423,00323,42923,46923,35923,387
824,67525,17625,05524,85425,183
1625,12825,62325,63525,69725,460
3225,08325,78825,70125,67125,678

HP EVA Partition Alignment - Reads per second

This shows an improvement in read IOPS of between 2% and 2.8%.

Writes/sec for each permutation of threads and offset

ThreadsUnaligned64K128K1MB2MB
116,23816,60016,68116,65916,578
216,63316,95017,04917,01716,987
417,18217,66117,65517,69117,685
817,37717,77717,82917,76917,760
1617,58317,96717,97217,93417,979
3217,67618,18518,12818,12218,100

HP EVA Partition Alignment - Writes per second

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.