SQL Server Performance Tuning

SQL Server Performance Tuning

SQL Server Performance tuning is a big topic and sometimes it becomes difficult to decipher the problem. So, in this blog topic, I am going to talk about generic steps to ensure, your SQL Server is running optimally. There are various 3rd Party monitoring tools like SQL Sentry, Redgate etc, but today we are only going to discuss about the tools and resources available out of the box for the majority of the SQL Server installations.

Disks:

Disks are the slowest part of the entire subsystem. In order for SQL Server to perform optimally, monitoring and optimizing the SQL Server Disk sub-system is very important. The Microsoft SQL Server Product team have very specific numbers recommended by them for Optimal Disk Performance.

Avg. Disk Sec/Read is the average time, in seconds, of a read of data from the disk. The following list shows ranges of possible values and what the ranges mean:

Less than 10 ms – very good
Between 10 – 20 ms – okay
Between 20 – 50 ms – slow, needs attention
Greater than 50 ms – Serious I/O bottleneck

Performance Monitoring & Analysis:

• You need to use *Performance Monitor* (Start>Run>Perfmon) and use the Data collector to capture the below mentioned counters. [Reference]
• You can use a time interval of 15 seconds or 30 seconds.
• Create a Data Collector Set from Performance Monitor
• Schedule Data Collection in Windows Performance Monitor (per day separate .blg file)
• Analyze through PAL tool at code plex Link: https://pal.codeplex.com/

Here are the performance counters –

• Processor: % Processor Time  Should average below 75% (and preferably below 50%).
• System: Processor Queue Length             Should average below 2 per processor. For example, in a 2-processor machine, it should remain below 4.
• Memory—Pages/sec     Should average below 20 (and preferably below 15).
• Memory—Available Bytes           Should remain above 50 MB.
• Memory – Free System Page Table Entries
• Memory – Pages Input/Sec
• Physical Disk—% Disk Time          Should average below 50%.
• Physical Disk—Avg. Disk Queue Length Should average below 2 per disk. For example, for an array of 5 disks, this figure should average below 10.
• Physical Disk—Avg. Disk Reads/sec          Used to size the disk and CPU. Should be below 85% of the capacity of the drive.
• Physical Disk—Avg. Disk Writes/ sec        Used to size the disk and CPU. Should be below 85% of the capacity of the drive.
• Network Interface—Bytes Total/sec       Used to size the network bandwidth.
• SQL Server: Buffer Manager— Buffer Cache Hit Ratio     Should exceed 90% (and ideally approach 99%).
• SQL Server: Buffer Manager—Page Life Expectancy        Used to size memory. Should remain above 300 seconds.
• SQL Server: Buffer Manager Lazy Writes/Sec
• SQL Server: Buffer Manager Checkpoint Pages/Sec
• SQL Server: Buffer Manager Page writes/sec
• SQL Server: General Statistics— User Connections           Used to size memory.
• SQLServer:General Statistics – Logins/sec
• SQLServer:General Statistics – Logouts/sec
• SQL Server: Databases— Transactions/sec           Used to size disks and CPU.
• SQL Server: Databases—Data File(s) Size KB        Used to size the disk subsystem.
• SQL Server: Databases—Percent Log       Used to size the disk subsystem.
• SQLServer:SQL Statistics Batch Requests/Sec
• SQL Server:Latches Average Latch Wait Time (ms)
• SQL Server:Locks Number of Deadlocks/sec
• SQL Server:Locks Lock Requests/sec
• SQL Server:Locks Average Wait Time (ms)
• Paging File %Usage

Disk Drive Placements:

Use separate drives for different purposes. (Log File, Data Files, Backup’s & TempDB)

Individual disk latency requirements:

Database >15ms, Logs> 2ms Tempdb> 2ms

Do not use the default allocation unit when formatting the Disk drives for SQL Server Log files & Data files:

Format drives with 64k Cluster Allocation Unit

Antivirus programs:

These programs can create issues with SQL Server functionality, and it is highly important to exclude them from their scan scope, by adding them to the exclusions list.

File types to exclude:

*.mdf, *.ndf, *.ldf, *.bak

Always Toggle the maximum memory setting on the SQL Server Instance level properties. Ensure at least 2GB – 4GB of RAM is available to the OS

Note: The maximum memory setting is only for the SQL Server buffer pool, and does not include memory requirements for other SQL Server functions like replication Services, Agent Job Service etc.

Ad

Storage Planning for TempDB

• Set the recovery model of TempDB to SIMPLE. This model automatically reclaims log space to keep space requirements small.
• Do not allow for TempDB files to automatically grow. This reduces the CPU overhead of managing a dynamic file growth.
• Have multiple data file for TempDB (Total Number of TempDB Primary Data File = Number of Processors available to SQL)
• Each data file should be of equal size.
• Try to keep each data files in separate disk drives for IO Parallelism.
• TempDB Data and Log files should be kept in faster disk drive (Preferably RAID 1 if possible)
• Use RAID-10 or SSD Disks.
• Pre-size TempDB files
• 25% of largest DB size.
• Set Auto Growth to fixed size < 200 MB
• You should have the same number of data files as the number of CPUs up to a maximum of 8.

Enable the Lock Pages in Memory Option (Windows)

This Windows policy determines which accounts can use a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk.

Max Degree of Parallelism 

If you have a multi-core CPU which have a high number of cores (<8), you can change the MAXDOP setting to 1 (Recommended for SharePoint 2010 & 2013, MS CRM). Too man threads can delay the performance of the SQL Server. See image below:

This should cover the basic Physical Server performance tuning best practices. Next we would discuss about the various tools available for analyzing SQL Server performance.