Achieving Peak PerformanceFrom Your Virtual SQL Servers

DBA-218David Klee, Founder

Heraflux Technologies

About David Klee

@kleegeekdavidklee.netgplus.to/kleegeeklinked.com/a/davidaklee

Specialties / Focus Areas / Passions:

• Performance Tuning• Virtualization• Infrastructure• Troubleshooting

• High Availability• Disaster Recovery• Capacity Management• Health & Efficiency

Please silence cell phones

Explore Everything PASS Has to Offer

Free SQL Server and BI Web Events Free 1-day Training Events Regional Event

Local User Groups Around

the World

Free Online Technical Training

This is Community Business Analytics Training

Session Recordings PASS Newsletter

Session Evaluations

ways to access

Go to

passsummit.com/evals

Download the GuideBook App

and search: PASS Summit 2014

Follow the QR code link displayed

on session signage throughout the

conference venue and in the

program guide

Submit by 11:59 PM ESTFriday Nov. 7 toWIN prizes

Your feedback is important and valuable.

Evaluation Deadline:

11:59 PM EST, Sunday Nov. 16

• What is Virtualization?

• What does Virtualization Mean for DBAs?

• Environmental Design & Performance Impact

• SQL Server Virtual Machine Construction

• SQL Server Workload Sizing

• It’s all About the Performance!

Agenda

• Most DBA’s virtualization experience…

• Added layer – removes hardware dependency from the

OS and above

• Hardware treated as physical resources

• All resources have queues

• Expect equivalent performance

What is Virtualization?

Historical Physical Model

SAN Disk Pool

Local Disks (OS, Instance Home)

SQL Server A

SQL Server B

Data

Logs

Data

Logs

Today’s Virtualization Model

SAN Disk Pool

LUN

LUN

LUN

VIR

TU

ALI

ZA

TIO

NVM

VM

VM

• Single compute node hardware

• Total cluster compute capacity

• Storage speed (IOPs, throughput)

• VM maximums

• Interconnect path speed

Hard Limits (Resources) Soft Limits (Queues)

• Memory oversubscription

• CPU scheduler contention

• Shared resource utilization

• Variable resource utilization levels

• “Noisy Neighbors”

Hard vs. Soft Limits

Resources

150 GHzCPU

4 TBMemory

4x10GbE

Network20 TBTier 1

Storage

40 TBTier 2

Storage

VM16 vCPU

128 GB vRAM

VM8 vCPU

64 GB vRAM

VM2 vCPU16 GB vRAM

VM2 vCPU16 GB vRAM

VM2 vCPU16 GB vRAM

VM2 vCPU16 GB vRAM

VM2 vCPU16 GB vRAM

VM2 vCPU16 GB vRAM

V I R T U A L I Z A T I O N

Queues

Hy

pe

rv

iso

r CPU SchedulerCPU

ExecutionCPU Scheduling Queue

Memory AllocatorMem R / W

Mem Allocation Queue

Disk SchedulerDisk R / W

Disk Scheduling Queue

Network SchedulerNetworkTran / Rec

Network Scheduling Queue

VM TASK

VM TASK

VM TASK

VM TASK

VM TASK

• Resource limits are easy to detect / work around

• Queue contention much harder

• Time in queue = time lost from VM

• Silent performance killer

• Everything in a VM must be scheduled

• … including idle resources

• Queue processing is not always FIFO

Goal: Minimize Queue Waits

• VMs cannot span physical servers

• Fastest CPU cores vs. overall core count

• Maximize host memory capacity

• No host memory overcommitment

• Monitor resource consumption & contention metrics

Host – Physical Server

• Most shared

• Most critical

• Most complex

• Most problematic

• Slowest piece of the stack

• Random I/O disk patterns

• Many individual points of contention

Storage

Storage – Contention Points

Controller

Controller

LUN

LUN

LUN

LUN

Disk Pool

VM

VM

VM

VM

• Test raw performance• SQLIO Batch

bit.ly/1mEAS9W

• DiskSpdbit.ly/1CeQauw

• Collect metrics:

• I/Os per second (IOPs)

• Latency (ms)

• Throughput (MB/s)

Storage - Maximums

0.00

10000.00

20000.00

30000.00

40000.00

50000.00

60000.00

70000.00

1 2 4 8 16 32 64 128

IOps

Thread Intensity

IOps Per Operations per Thread

Sequential Read

Random Read

Sequential Write

Random Write

• Huge performance bottleneck potential

• Get fastest possible!

• Get most possible!

• Multi-pathing configuration / software

• Vendor-recommended HBA queue depth settings

• Verify and test end-to-end performance

Network & Storage Interconnects

• Verify network end-to-end performance

• Use iperf to test network throughput

• bit.ly/1eDCYbi

• How-To Guide: bit.ly/YET53p

Network Throughput Testing

• Co-locate VMs on same physical machine

• Same vNetwork, improved performance

Physical Proximity

• CPU

• vCPU counts

• vNUMA configuration

• Hot-add?

• Memory

• Full memory reservation

• Dynamic memory

• Hot-add?

VM Configuration

• Storage

• Virtual disks whenever

possible

• Multiple virtual disks

“Right-Size” it!

• “Right” amount of vCPU and vRAM resources

• Physical world = Size for end of life

• Virtual world = Size for right now

• Idle vCPUs will slow application VMs performance

• Analyze performance baselines and determine

the resources you need

• Repeat “right-sizing” analysis routinely

“Right-Sizing” the VM

• Not done at just vCPU count

• vNUMA configuration also matters

• Closely align with pNUMA

• Adds efficiency by aligning with underlying hardware

• Performance difference improves with larger VMs

CPU Sizing - NUMA

• Get physical machine configuration

• Try to fit VM inside one NUMA node

• Otherwise, balance across number

of NUMA nodes

• Test configurations for best results

CPU Sizing - vNUMA

• Example: 16 vCPU VM

• What’s better?

• 2 vSocket x 8 vCore?

• 4 vSocket x 4 vCore?

• 8 vSocket x 2 vCore?

• Varies by workload,

hardware

• Test it for yourself!

CPU Sizing – vNUMA Results

0

100000

200000

300000

400000

500000

600000

700000

800000

900000

8 16 64 256

Tra

nsa

ctio

ns

/ m

inConcurrent HammerDB Users

vNUMA SQL Server Scalability - 16 vCPUs - HammerDB

4socket x 4CPU 8socket x 2CPU 2socket x 8CPU

• SQL Server data must be in buffer pool

• More memory ≈ less I/O

• Less I/O = less waiting on shared storage & queues

• NO HOST MEMORY OVERCOMMITMENT

• Too much memory = lower consolidation ratio

• Balancing act

Memory

C: - Operating System

D: - SQL Server Instance Home

E: - System Databases (master, model, msdb) *

F: - User Database Data (1 of X)

G: - User Database Log (1 of Y)

H: - TempDB

Y: - Windows Page file **

Z: - Backups

vDisk Layout

Adjust as necessary

(but stay standardized)

• Set power settings to “High Performance” (CPU-Z)

• Set antivirus exclusions for SQL Server (tinyurl.com/sqlav)

• Ongoing OS-level performance metric collection

• No greater than five minute interval

• 24 x 7, not just as-needed

• Windows Perfmon, Microsoft SCOM,

or any other third-party utility

• tinyurl.com/kleeperfmon

Operating System

• Goal: Maximize performance while reducing resource

scheduling

• Parallelizable workloads

• Determine how parallel the workload is

• Set MaxDOP = vNUMA node core count (?)

• Cost threshold for parallelism = Not default

SQL Server

• Spread out the I/O

• File groups, data files, partitions

• Parallelism with multiple active storage paths

• Reduce I/O

• Table & index compression

• In-memory constructs

• More RAM

• SSD read / write caching

SQL Server Database

• You can virtualize it successfully!

• Understand your SQL Server workloads• Individual

• Aggregate

• “Right-size” your VMs & baseline performance

• Routinely check ongoing performance

Conclusions

Contact Me!davidklee.net @kleegeek

Questions?Thanks for attending!