Why new hardware may not make SQL Server faster

Throwing Hardware at SQL Server Performance problems?
Think again, there’s a better way!
SQL Server Performance

Approaches to Performance Improvement
» Buy bigger, faster hardware
 Sometimes the only answer
 Often the easy way out
 Can be high risk
» New SQL Server features
 May help if your problem is one they address
» Make better use of existing resources
 Start by understanding the issues
 Gather and analyze information
 Make informed decisions
 Be proactive

Performance information
» Many sources
 Dynamic Management views
 System Tables
 WMI
 Performance counters
» Needs to be stored and correlated
 History
 Baselines
 Microsoft tools
• Often a “science project”
 Commercial tools
• History and correlation sometimes built in
• Help with analysis and resolution
• Database Performance Advisor (DPA) does both

Hardware Settings
» Power Saver Mode
 Defaults to Balanced
 SQL Server works better on High Power
 https://support.microsoft.com/kb/2207548?wa=wsignin1.0
» HBA Queue Depth
 Defaults to 16 or 32
 SQL Server needs 64 or 128

Storage Issues
» Data, Logs, and Tempdb on separate volumes
» RAID 10 for faster writes than RAID 5
» MPIO – load balanced
» Compression reduces IO by increasing rows per page
» Table and index scans increase IO
 Indexes
 Query tuning
» Disk Performance
 Seconds Per Read - < 10 ms
 Seconds Per Write < 5 ms

Parallelism
» Limits on speed of a core
» Adding cores to improve performance
 Multiple queries in parallel
 Multiple cores for a single query
• Scan in parallel
• Sort/filter in parallel
 Hyper-threading works in current versions
» CXPACKET wait type indicates parallelism is being used
 Not necessarily a bad thing
 Many large queries can produce high CXPACKET waits

MAXDOP
» Limits the number of schedulers for a query
 Set at instance level or query hint
 Defaults to 0 – all schedulers on system
 Too much parallelism can be bad
• Competition for processor resources
• Splitting and combining overhead
• Crossing NUMA boundaries
• Servers may have > 64 cores which is more than most queries can use effectively
 MAXDOP <= NUMA node size
 MAXDOP = 8 good place to start

Cost Threshold for Parallelism
» Optimizer creates serial plan first
» If the cost of the serial plan is greater than the Cost Threshold for Parallelism it
creates a parallel plan
» The lowest cost plan is used
» Cost Threshold default is 5
» With modern servers, 5 is much to small
 Waste time and processor cycles computing parallel plans
 May use parallel plan for very small queries
» Start with 25-30 and if it helps try 40 or 50

Buffer Cache
» Cache pages so query engine doesn’t have to go to disk
» Low buffer cache = increased IO
» Measure memory stress
 Page Life Expectancy (PLE) – estimated time page will stay in memory
• Larger the better
• Look for sudden drops in PLE
• Large table scans
• Lots of IO to reload cache
 Lazy Writes
• Short on memory – dirty pages flushed to disk between checkpoints
» Fix buffer cache issues
 Reduce table scans
 Increase memory

Plan Cache
» Compiled plans are stored in cache for possible reuse
 Lookup by hash of query text
• Must be exact match
 Plan not reused are gradually aged out of cache
» Single use plans
 Usually non-parameterized queries
 Waste cache space – slow search for plans
 OPTIMIZE FOR ADHOC QUERIES instance parameter
• Caches queries on second use
• Saves cache space
• Use routinely
 FORCED PARAMETERIZATION
• Makes optimizer more aggressive about parameterizing queries
• Use only after testing
• Only when rewriting queries isn’t possible

Table and Index Scans
» Query needs to access all rows
 Aggregates
 Reports
» Scan is the best way to execute the query
 Not many rows
 Most of the rows required
» No index on the column
» There is an index but it can’t be used
 Implicit datatype conversions
 Scalar functions

Wait Analysis
» SQL tasks are either executing or waiting
» Understanding what tasks are waiting for can help you find performance issues
» DPA offers several ways to analyze waits
 System wide waits – what does the system wait for
 Waits by query – what waits make up the response time of a query
» DPA helps analyze query performance
 Which queries take the most time
 Which queries run most often
 Which queries use the most resources
» DPA analyzes tends
 Resource usage changing
 Queries running slower

Database Performance Analyzer Demo
Janis Griffin
» Database Performance Evangelist
» SolarWinds – The Power to Manage IT

First steps
» Check Power Saver and HBA settings
» Implement data compression
» Set MAXDOP to 9 and Cost Threshold for Parallelism to 30
» SET OPTIMIZE FOR ADHOC QUERIES option
» Set up monitoring for (at least)
 Tables Scans
 PLE
 Lazy Writes
 Seconds per Write
 Seconds per Read
» Check for missing indexes and tune most expensive queries

Summary
» Investing in hardware without first understanding performance issues is a high risk
option
» Gathering performance information is key to understanding and resolving
performance issues
» Baselines and history are important to performance analysis
» Wait analysis can help diagnose performance issues

© 2014 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.
Resolve performance issues quickly—free trial
» Try Database Performance Analyzer FREE for 14 days
» Improve root cause of slow performance
 Quickly identify root cause of issues that impact end-user response time
 See historical trends over days, months, and years
 Understand impact of VMware® performance
 Agentless architecture with no dependence on Oracle Packs, installs in minutes
www.solarwinds.com/dpa-download/

Questions?

Thank You!
The SOLARWINDS and SOLARWINDS & Design marks are the exclusive
property of SolarWinds Worldwide, LLC, are registered with the U.S.
Patent and Trademark Office, and may be registered or pending
registration in other countries. All other SolarWinds trademarks, service
marks, and logos may be common law marks, registered or pending
registration in the United States or in other countries. All other
trademarks mentioned herein are used for identification purposes only
and may be or are trademarks or registered trademarks of their respective
companies.

Why new hardware may not make SQL Server faster

More Related Content

What's hot (19)

Viewers also liked (20)

Similar to Why new hardware may not make SQL Server faster (20)

More from SolarWinds (20)

Recently uploaded (20)

Why new hardware may not make SQL Server faster