Your SQL Servers are probably virtualized by now, but are they running at their absolute peak performance? How can you tell? When properly configured and maintained, a virtualized SQL Server will be at least as fast as the system that it came from, if not better. If not properly configured, silent performance killers can wreck your virtualization experience. This session will give you tips and tricks to maximize performance while giving you talking points so you can convince your infrastructure engineers to design the virtualization stack your way. This session goes deep into the architecture and methodology for squeezing the best possible performance from your virtualized SQL Server, and includes valuable tips on topics such as host-level over-commitment, storage performance, In-memory OLTP, and more!

1. Achieving Peak
Performance
From Your Virtual SQL Servers
DBA-218David Klee, Founder
Heraflux Technologies

2. About David Klee
@kleegeek
davidklee.net
gplus.to/kleegeek
linked.com/a/davidaklee
Specialties / Focus Areas / Passions:
• Performance Tuning
• Virtualization
• Infrastructure
• Troubleshooting
• High Availability
• Disaster Recovery
• Capacity Management
• Health & Efficiency

3. Please silence
cell phones

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

5. 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 EST
Friday Nov. 7 to
WIN prizes
Your feedback is
important and valuable.
Evaluation Deadline:
11:59 PM EST, Sunday Nov. 16

6. • 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

7. • 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?

8. Historical Physical Model
SAN Disk Pool
Local Disks (OS, Instance Home)
SQL Server A
SQL Server B
Data
Logs
Data
Logs

9. Today’s Virtualization Model
SANDisk Pool
LUN
LUN
LUN
VIRTUALIZATIONVM
VM
VM

10. • 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

11. Resources
150
GHz
CPU
4 TB
Memory
4x10GbE
Network
20 TB
Tier 1
Storage
40 TB
Tier 2
Storage
VM
16 vCPU
128 GB vRAM
VM
8 vCPU
64 GB vRAM
VM
2 vCPU
16 GB
vRAM
VM
2 vCPU
16 GB
vRAM
VM
2 vCPU
16 GB
vRAM
VM
2 vCPU
16 GB
vRAM
VM
2 vCPU
16 GB
vRAM
VM
2 vCPU
16 GB
vRAM
V I R T U A L I Z A T I O N

12. Queues
Hypervisor
CPU Scheduler
CPU
Execution
CPU Scheduling Queue
Memory Allocator
Mem
R / W
Mem Allocation Queue
Disk Scheduler
Disk
R / W
Disk Scheduling Queue
Network Scheduler
Network
Tran / Rec
Network Scheduling Queue
VM TASK
VM TASK
VM TASK
VM TASK
VM TASK

13. • 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

14. • 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

15. • Most shared
• Most critical
• Most complex
• Most problematic
• Slowest piece of the stack
• Random I/O disk patterns
• Many individual points of contention
Storage

16. Storage – Contention Points
Controller
Controller
LUN
LUN
LUN
LUN
Disk Pool
VM
VM
VM
VM

17. • Test raw performance
• SQLIO Batch
bit.ly/1mEAS9W
• DiskSpd
bit.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

18. • 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

19. • Verify network end-to-end performance
• Use iperf to test network throughput
• bit.ly/1eDCYbi
• How-To Guide: bit.ly/YET53p
Network Throughput Testing

20. • Co-locate VMs on same physical machine
• Same vNetwork, improved performance
Physical Proximity

21. • 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!

22. • “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

23. • 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

24. • 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

25. • 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
Transactions/min Concurrent HammerDB Users
vNUMA SQL Server Scalability - 16 vCPUs - HammerDB
4socket x 4CPU 8socket x 2CPU 2socket x 8CPU

26. • 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

27. 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)

28. • 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

29. • 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

30. • 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

31. • You can virtualize it successfully!
• Understand your SQL Server workloads
• Individual
• Aggregate
• “Right-size” your VMs & baseline performance
• Routinely check ongoing performance
Conclusions

32. Contact Me!
davidklee.net @kleegeek

33. Questions?
Thanks for attending!