This document discusses "right-sizing" a SQL Server virtual machine (VM) by properly allocating CPU, memory, and storage resources. It explains that one size does not fit all workloads and inappropriate allocations can hurt performance. The presenter recommends profiling systems by collecting metrics from all stack components, analyzing workloads, and adjusting VM configurations based on the data. Regular reviews are also advised as workloads change. A new free beta tool is announced that will automate estimating the right-sized resource assignment for a SQL Server VM.
5. 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
6. 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
7. • What is “right-sizing”, and why
• Profiling the system stack components
• CPU / memory / storage
• Analyzing environment
• Workload analysis
• Perfmon data review
Agenda
8. • Abstraction layer between hardware and OS
• Resources
• Queues
• Limits in the environment
• Resource limitations (hard)
• Queue contention (soft)
What Is Virtualization - for DBAs?
9. • VM resource allocations
• vCPU
• Memory
• Storage presentation
• One size does not fit all workloads
• Inappropriate resource allocations
can hurt VM performance
“Right-Sizing”?
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
16. • 24x7 performance metric
collection
• CRITICAL
• Metrics from every piece
of the system stack
Performance Metric Collection
Networking
Interconnects
Physical Server
Virtualization
Operating System
SQL Server Instance
SQL Server DB
Application
Storage
17. • SQL Server
• Raw CPU / mem / disk
usage
• NUMA memory usage
• Signal waits
• Storage latency by DB file
• Wait statistics
• Glenn Berry @ bit.ly/1wdMB8n
Which High Level Metrics?
• Windows
• CPU & memory consumption
• Storage IOPs / latency /
throughput
• Processes (SQL Server vs other)
• Perfmon how-to @ bit.ly/1sqSVns
• @ bit.ly/1xW4jzJ
Capture all metrics as granularly as possible!
18. • Virtualization
• Resource consumption by
VM
• Resource utilization by host
• CPU scheduling queue wait
• Overcommitment metrics
• VMware vSphere: CPU Ready
• MS Hyper-V: CPU Wait Time
per Dispatch
Which High Level Metrics?
• Storage
• IOPs / latency / throughput
• By LUN
• By disk group
• Controller
• Interconnect path utilization
• Controller cache hit metrics
Capture all metrics as granularly as possible!
19. • Overlay all data streams
• Understand / classify:
• Workload periods
• Workload sources
• Business time period
• Goal: metrics by time
period
How to Analyze
• Median & Percentile analysis
• Explain & filter statistical
anomalies
• Statistics
• Min / Average / Max / Median
• Percentile
21. • vCPU counts matter!
• Size for what you need today
• Too many vCPUs = BAD (probably)
• Too few vCPUs = BAD (usually)
• Workload / server specific
vCPU Sizing
22. • 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
23. • 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
24. • 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
25. • SQL Server
• CPU consumption by DB
• Top waits
• Signal waits
• Scrape parallelism from
execution plan @
bit.ly/1rTs9UX
CPU - Metrics
• Windows
• CPU usage per core
• SQL Server vs. background
• VM Host
• CPU utilization over 80%
• VM CPU queue waits high
26. • Understand the workload parallelism, concurrent volume
• Determine averages, maximums, and percentiles
• Determine the appropriate profiling period
• < 40% utilization avg – too many CPUs
• > 60% utilization avg – too few CPUs
• Factor CPU waits inside SQL Server
• Vary according to your circumstances
How To Size vCPUs
28. • 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 VM consolidation ratio
• Balancing act
Memory
29. • SQL Server
• Page Life Expectancy
• Buffer Cache Hit Ratio
• High page fault count
• High recompile ratio
• RESOURCE_SEMAPHORE
waits
• Memory grants pending
Memory - Metrics
• Windows
• MB free
• Paging
• VM Host
• Memory consumption > 90%
• Memory ballooning /
dynamic memory expansion
30. • How much memory?
• Slow storage? More RAM!
• Fast storage? Less RAM?
• More RAM = less host-level consolidation
• More SQL Server licensing (possibly)
• Table / index compression
How To Size vRAM
32. • Much less variable in nature
• Most shared resource
• Most critical
• Most complex
• Most problematic
• Slowest piece of the stack
• Random I/O disk patterns
• Many individual points of contention
Storage
33. Storage – Contention Points
Controller
Controller
LUN
LUN
LUN
LUN
Disk Pool
VM
VM
VM
VM
34. • 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
35. Storage – Spread Out Workload SAN
DB
E:
FG1
FG2
DF4
DF3
DF2
DF1
G:
F:
WindowsServerOSx
Virtualization
Hardware
HBA4HBA3HBA2HBA1
InterconnectSwitch
Controller1Controller2
SANDiskGroup
LUN2LUN1
HBA4HBA3HBA2HBA1
39. • Workloads & applications change
• DBs are added / removed
• Perform a right-sizing analysis as necessary
• Adjust the VM resources accordingly
• Recommended: Periodic review of VM sizing
• Quarterly for volatile environments
Not a One-Time Process
40. • One VM size does not fit all workloads
• Profile and record your workload performance
characteristics
• Analyze the numbers
• Adjust VM configuration and validate
• Repeat as often as your workload changes
Summary
41. This is a pain!
Shouldn’t this be easier?
But Wait!
