Microsoft SQL Server Performance Basics (I/O Performance)
There are a lot of settings that you can tweak to get higher performance out of your Microsoft SQL Server. The most basic one is IO performance, i.e. disk performance. Usually when I talk to people about this I get the response that this is an art form and something that most techs don’t know about or feel that they don’t understand. Most people rely on the SAN team to take care of this but if you don’t understand this and can inform the SAN team what you need you will get the standard. Most SAN system are optimized for There are always more tweaks that can be applied but in most cases the further you come along this line the smaller impact the changes have. In this article I would like to point out the most basic, and important, performance issues with Microsoft SQL Server that are easy to address. These are independent of size of the solution or underlying hardware e.g. local attached discs or SAN.
Background
To understand why this is so important you need to know a little about how Microsoft SQL Server reads from the disk. To simplify Microsoft SQL Server reads pages, pages contains a number of rows with you corresponding data. The pages with extents are 64kb in size. So the goal here is to read (or write) the page with as few disc IO’s as possible.
Stripe Unit Size
The stripe size is the smallest chunk of data that can be addressed within the RAID. So make sure you are using at least 64KB stripe size. If it’s a larger number like 128KB or 256KB that only means that you can write several more pages in the same stripe, this can actually benefit performance of the read ahead function in Microsoft SQL Server.
File allocation unit size / Disc cluster size
This setting is on the file system level. Microsoft SQL Server is designed for the NTFS file system and the default NTFS disc cluster size is 4KB. Again this should be 64KB for best performance, it enables SQL server to do less IO than a smaller cluster size does. There is a correlation between cluster size and stripe unit size that needs to be meet for optimal performance:
Stripe Unit Size ÷ File Allocation Unit Size = an integer
If possible you should try to meet this formula. However that isn’t always possible due to different storage systems. The most important thing for performance in that case is to use the 64KB cluster size! The formula for partition alignment below is however not optional for performance!
Partition alignment (partition offset)
When I have been talking to people about this most people look at me like I’m crazy. A system that was setup from a clean install of Microsoft Windows Server 2008 and later doesn’t suffer from this, these versions do an automatic alignment of the partition. If the partition isn’t aligned your server will end up splitting the read and write IO into two or more IO’s. This is very bad for performance.
Role of thumb here is:
Partition Offset ÷ Stripe Unit Size = an integer
Old systems prior to Microsoft Windows Server 2008 could end up with a 31.5KB offset (63 hidden sectors * 512b sectors). Doesn’t matter what stripe unit size you have 4,8,16,32,64,128…. It will never make the equation spit out an integer! Therefor bad for performance!
So if your system is prior to Microsoft Windows Server 2008 or have disk partitions created by an earlier version, check the partition offset! It’s easily done by running this command:
wmic partition get BlockSize, StartingOffset, Name, Index
To check the stripe size you have to refer to your storage controller. Standard offset in Microsoft Windows Server 2008 and later is 1024KB and it doesn’t really matter what stripe unit size you have, you will still end up with an integer.
Log files
For SQL server log files you should use RAID 1 both for best read/write performance but also for the extra data security. In a raid one you can lose 50% of your disks without losing data, neither RAID 5 or RAID 10 can guaranty this data safety. It will however cost you half of the storage space.
Do you want to read more?
http://technet.microsoft.com/en-us/library/dd758814(v=sql.100).aspx
Written by Jimmy May, Denny Lee and goes deeper into the techniques.
Hackviking aka Kristofer Källsbo 