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

Why new hardware may not make SQL Server faster

Embed Size (px)

Citation preview

Page 1: 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

Page 2: Why new hardware may not make SQL Server faster

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

Page 3: Why new hardware may not make SQL Server faster

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

Page 4: Why new hardware may not make SQL Server faster

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

Page 5: Why new hardware may not make SQL Server faster

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

Page 6: Why new hardware may not make SQL Server faster

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

Page 7: Why new hardware may not make SQL Server faster

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

Page 8: Why new hardware may not make SQL Server faster

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

Page 9: Why new hardware may not make SQL Server faster

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

Page 10: Why new hardware may not make SQL Server faster

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

Page 11: Why new hardware may not make SQL Server faster

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

Page 12: Why new hardware may not make SQL Server faster

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

Page 13: Why new hardware may not make SQL Server faster

Database Performance Analyzer Demo

Janis Griffin

» Database Performance Evangelist

» SolarWinds – The Power to Manage IT

Page 14: Why new hardware may not make SQL Server faster

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

Page 15: Why new hardware may not make SQL Server faster

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

Page 16: Why new hardware may not make SQL Server faster

© 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/

Page 17: Why new hardware may not make SQL Server faster

Questions?

© 2014 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.

Page 18: Why new hardware may not make SQL Server faster

© 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.