is this really a san problem? understanding the performance of your io subsystem

EMBARCADERO TECHNOLOGIESEMBARCADERO TECHNOLOGIES

Is This Really a SAN Problem?Understanding the Performance ofYour I/O Subsystem

Joey D’Antoni

16 September 2015

EMBARCADERO TECHNOLOGIES

Joey D’Antoni

• Joey has over 15 years of experience with a wide variety of data platforms, in both Fortune 50 companies as well as smaller organizations

• He is a frequent speaker on database administration, big data, and career management

• He is the co-president of the Philadelphia SQL Server User’s Group

• MSCE, Business Intelligence, Database Administration

• He wants you to make sure you can restore your data

Joeydantoni.com


Agenda

SAN and Storage Architecture

The Language of the SAN Admin

How SQL Server uses Storage

Troubleshooting Performance Issues

Summary


Poll

Who Are You?


Bottlenecks


Memory versus Hard Drives


Storage Area Network


What is a SAN?

Basically a specialized

computer for storage

Computer, Switches and Hard

Drives

Not a performance device

Can be used for redundancy and DR

purposes

Will serve many servers—so critical

piece of your infrastructure


SAN Components

HBA (Fibre) Card—Connects your server to SAN via Fiber Optic cable

iSCSI Card—Ethernet Card connecting server to SAN

Switch—Either fibre or ethernet switch connecting server to SAN

SAN head unit—Controls processing, RAID levels

Disk Array—The physical array behind your SAN (a bunch of hard drives)


SAN Terms

LUN—Logical Unit Number, but in practical terms, what your SAN admin will call a disk that he presents to your server

Fibre Channel—Cable connection to SAN

IOPs—I/O Operations Per Second—the way your SAN admin measures performance


Multi-Pathing

How your SAN admin sleeps at night!

Make sure your databases servers are multi-pathed


SAN Throughput

0 200 400 600 800 1000 1200 1400

1 GB iSCSI

4 GB FC

8 GB FC

10 GB iSCSI

Max Mb/S

Max Mb/S


Tiered Storage (Example—EMC VMax)

Allows for dynamic moves of disk from faster to slower disks (Fibre channel to SATA), or slower to faster (FC to SSD)

Totally dynamic, and seamless to servers

Moves data in 768k extents

Your SAN admin doesn’t know where your data is


FAST VP

SSD SSD SSD

15K Fibre Channel 15k Fibre Channel 15k Fibre Channel

10K SATA 10K SATA 10K SATA

Log

Data


How to Tune a SAN

Properly configure the array

Spend lots of money


Poll

How Frequently Do You Meet with Your SAN Team?


SQL Server and Storage


SQL Server Storage

SQL Server uses 8k pages to store data

Data is read page by page

Data is written page by page

Pages are grouped into 64k extents

I/O patterns are mixed random and sequential

Logical and Physical Reads


Large I/O Operations in SQL Server

Checkpoints

Scans

Check DB

Transaction Logging


Sequential Operations

Transaction Log writes

Backup

Read-Ahead


Writing Pages to Disk

Lazy WritingEager

writingCheckpoints


SQL Server I/O Demo


How to Monitor I/O in SQL Server

• DMVs

• Windows/Perfmon

• Correlate Profiler/Perfmon


Poll

How Do You Monitor Performance Over Time?


Perfmon Demo


What Perfmon Counters are Good/Bad for SQL and SANs• Avg. Disk Bytes/Read• Avg. Disk Bytes/Transfer• Avg. Disk Bytes/Write• Avg. Disk sec/Read• Avg. Disk sec/Transfer• Avg. Disk sec/Write• Disk Bytes/sec• Disk Read Bytes/sec• Disk Reads/sec• Disk Transfers/sec• Disk Write Bytes/sec• Disk Writes/sec• Split I/O/Sec

• % Disk Read Time• % Disk Time• % Disk Write Time• % Idle Time• Avg. Disk Queue Length• Avg. Disk Read Queue Length• Avg. Disk Write Queue Length• Current Disk Queue Length


What to Look for in SQL Server

Missing Indexes

Queries with scans

Page Life Expectancy

It is very important to baseline this data—before and after are critical


8 Tips for DBAs

Baseline test your SAN before it gets loaded

Baseline your SQL Server Performance

Understand any changes in user workload through your baselines

Work with storage team to understand your storage environment

Be careful of SAN firmware upgrades

Don’t blame the SAN until you have all of your data in place

If performance is absolutely critical use local storage

SANs, while cool, are not magic


Summary

Learn how the SAN works, what it does and does not do

Understand when and where SQL Server does its I/O

SANs may not measure frequently enough

Windows gives the best storage information

You need to trend this data overtime to really understand your environment


Questions

is this really a san problem? understanding the performance of your io subsystem

Software