Throwing Hardware at SQL Server Performance problems? Think again, there’s a better way! SQL Server Performance
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?
© 2014 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.
© 2014 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.
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.