vSphere APIs for performance monitoring

20,117 views

Published on

Published in: Technology, Sports
2 Comments
14 Likes
Statistics
Notes
No Downloads
Views
Total views
20,117
On SlideShare
0
From Embeds
0
Number of Embeds
889
Actions
Shares
0
Downloads
671
Comments
2
Likes
14
Embeds 0
No embeds

No notes for slide

vSphere APIs for performance monitoring

  1. 1. vSphere APIs for performance monitoring London Workshop October – 2010 Balaji Parimi, Staff Engineer, Ecosystem Performance, VMware, Inc. Ravi Soundararajan, Senior Staff Engineer, Performance, VMware, Inc.
  2. 2. Motivation To debug performance, why deal with this...?
  3. 3. Motivation When you can deal with this instead?
  4. 4. More motivation Why look at data like this…? Before memhog: no guest swapping After memhog, guest swaps, but Host does not!
  5. 5. More motivation When you can look at it like this?
  6. 6. Even more motivation… Why compare resource pool performance like this…?
  7. 7. Even more motivation When you can compare them like this…?
  8. 8. Why? vSphere gives you awesome, helpful charts But you don’t have to rely solely on these charts Do you want to learn how to make your own charts? • Keep watching
  9. 9. Goal Teach you how to use our APIs for performance monitoring
  10. 10. Agenda What sorts of stats are useful? How does vSphere retrieve them? How can you get these stats and use them yourself?
  11. 11. Useful stats Basics of performance monitoring in virtual infrastructure • Find underperforming resources • Find overcommitted resources • Identify issues due to resource sharing among VMs Resources we will look at • CPU • Memory • Disk • Network
  12. 12. Resources that we often look at CPU Memory Disk Network
  13. 13. CPU basics ESX CPU0 CPU1 CPU2 CPU3 VM0 VM1 VM2 VM3 VM4 Run (accumulating used time) Ready (wants to run, no physical CPU available) Wait: blocked on I/O or voluntarily descheduled VM5 VM6 Run Ready Wait/Idle
  14. 14. Why is my VM slow? CPU saturated (cpu.usage.average) Ready time? (cpu.ready.summation) Latency to be swapped in? (cpu.swapwait.summation)
  15. 15. CPU saturation 2 vCPUs 2.2GHz/CPU ~4.4GHz used (Look at left y-axis)
  16. 16. Small ready time Ready time vCPU1: 150ms Real-time chart: refresh 20s 150ms / 20s = 0.75% (No big deal) Right y-axis is relevant
  17. 17. Now, turn on CPU burner on same host… CPU burner ~100% of 1 vCPU
  18. 18. And see what happens to original VM’s ready time SpecJBB ready time ~2000ms = 10% (ps. SpecJBB perf. dropped by 10%)
  19. 19. Latency to load in VM: cpu.swapwait.average Sometimes there is a latency to load VM data from disk: cpu swapwait CPU takes 20s to load in data before VM can run!
  20. 20. CPU issues: Summary CPU saturated? High Ready time • Problematic if it is sustained for high periods • Sample rule of thumb: > 20% per vCPU investigate further • Possible contention for CPU resources among VMs • Workload Variability? Fix with VMotion/DRS • Resource limits on VMs? Check Limits, reservations and shares • Actual over commitment? Fix with Vmotion/DRS/more CPUs High SwapWait time • Consider setting memory reservation (see next section, “Memory”)
  21. 21. Resources that we often look at CPU Memory Disk Network
  22. 22. Memory ESX must balance memory usage • Page sharing to reduce memory footprint of Virtual Machines • Ballooning to relieve memory pressure in a graceful way • Host swapping to relieve memory pressure when ballooning insufficient • Compression to relieve memory pressure without host-level swapping ESX allows over commitment of memory • Sum of configured memory sizes of virtual machines can be greater than physical memory if working sets fit Memory also has limits, shares, and reservations Host swapping can cause performance degradation
  23. 23. VM1 Ballooning, compression, and swapping (1) Ballooning: Memctl driver grabs pages and gives to ESX • Guest OS choose pages to give to memctl (avoids “hot” pages if possible): either free pages or pages to swap • Unused pages are given directly to memctl • Pages to be swapped are first written to swap partition within guest OS and then given to memctl Swap partition w/in Guest OS ESX VM2 memctl 1. Balloon 2. Reclaim 3. Redistribute F
  24. 24. Swap Partition (w/in guest) Ballooning, swapping, and compression (2) Swapping: ESX reclaims pages forcibly • Guest doesn’t pick pages…ESX may inadvertently pick “hot” pages ( possible VM performance implications) • Pages written to VM swap file VM1 ESX VM2 VSWP (external to guest) 1. Force Swap 2. Reclaim 3. Redistribute
  25. 25. ESX Compression Cache Ballooning, swapping and compression (3) Compression: ESX reclaims pages, writes to in-memory cache • Guest doesn’t pick pages…ESX may inadvertently pick “hot” pages ( possible VM performance implications) • Pages written in-memory cache faster than host-level swapping Swap Partition (w/in guest) VM1 VM2 1. Write to Compression Cache 2. Give pages to VM2
  26. 26. Ballooning, swapping, and compression Bottom line: • Ballooning may occur even when no memory pressure just to keep memory proportions under control • Ballooning is preferable to compression and vastly preferably to swapping • Guest can surrender unused/free pages • With host swapping, ESX cannot tell which pages are unused or free and may accidentally pick “hot” pages • Even if balloon driver has to swap to satisfy the balloon request, guest chooses what to swap • Can avoid swapping “hot” pages within guest • Compression: reading from compression cache is faster than reading from disk
  27. 27. Swapping in Guest! = Swapping in Host DVDstore benchmark: SQL DB benchmark… uses lots of memory About to start memory hogger program in guest
  28. 28. Force Guest swapping: No Host-level swapping Before memhog: no guest swapping After memhog, guest swaps, but Host does not!
  29. 29. Viewing Host-level swapping with performance charts Setup: 2 VMs…one dvdstore, one memhog, competing for host memory Host swaps out dvdstore VM memory to fulfill memhog VM requests Host swaps in dvdstore VM memory to fulfill dvdstore VM requests
  30. 30. Using Swap Rate Counters: Remember CPU SwapWait? Cpu.swapwait.summation: CPU is waiting for memory to be swapped in
  31. 31. Absolute Swap Counters… Swapin, swapout (KB) show some activity but hard to detect…
  32. 32. And Swap Rate Counters… SwapinRate, SwapoutRate (KBps) show activity much more clearly Rule of thumb: host swapping > 1MBps is cause for concern
  33. 33. Resources that we often look at CPU Memory Disk Network
  34. 34. ESX storage stack Different latencies for local disk vs. SAN (caching, switches, etc.) Queuing within kernel and in hardware vSphere shows • Total Command Latency • Kernel Latency • Device Latency • Bandwidth/IOPS
  35. 35. Disk performance problems 101 What should I look for to figure out if disk is an issue? • Am I getting the IOPs I expect? • Am I getting the bandwidth (read/write) I expect? • Are the latencies higher than I expect? • Where is time being spent? What are some things I can do? • Make sure devices are configured properly (caches, queue depths) • Use multiple adapters and multipathing • Check networking settings (for iSCSI/NAS)
  36. 36. Another disk example: Slow VM power on Trying to Power on a VM • Sometimes, powering on VM would take 5 seconds • Other times, powering on VM would take 5 minutes! Where to begin? • Powering on a VM requires disk activity on host Check disk metrics for host
  37. 37. Let’s look at the vSphere client… Max Disk Latencies range from 100ms to 1100ms…very high! Why? (counter name: disk.maxTotalLatency.latest) Rule of thumb: latency > 20ms is Bad. Here: 1,100ms REALLY BAD!!!
  38. 38. High disk latency: Mystery solved Host events: disk has connectivity issues high latencies! Bottom line: monitor disk latencies; issues may not be related to virtualization!
  39. 39. Resources that we often look at CPU Memory Disk Network
  40. 40. Network performance problems 101 What should I look for to figure out if network is an issue? • Am I getting the packet rate that I expect? • Am I getting the bandwidth (read/write) I expect? • Is all traffic on one NIC, or spread across many NICs? • [more advanced… not available through counters]: out-of-order packets? What are some things I can do? • Check host networking settings • Full-duplex/Half-duplex • 10Gig network vs 100Mb network? • Firewall settings • Check VM settings: all VMs on proper networks?
  41. 41. Network performance troubleshooting Customer complains about slow network • She’s running netperf on a GigE Link • She sees only 200Mbps • Why? I bet it’s that VMware stuff!! • Note to reader: Please don’t blame VMware first ☺ Where do we start?
  42. 42. All VMs using same NIC (VM network) All VMs using “VM Network” and sharing 1 physical NIC
  43. 43. Where do we begin? Check VM bandwidth Measure VM Bandwidth (net.transmitted.average) • 200 Mb/s • Screenshot from the vSphere client
  44. 44. Check Host Bandwidth Measure Host Bandwidth (net.transmitted.average) • Host sees around 900Mbps…why is VM at 200Mbps? • Hmm… are we sharing this NIC with multiple VMs?
  45. 45. All traffic is going through one NIC! Measure per-physical-NIC traffic Hmm… all VM traffic is going through 1 NIC Let’s split the VMs across NICs All traffic through one NIC on this host
  46. 46. Split VMs across multiple NICs. Bingo!
  47. 47. Network issues: Configuration woes Network adapter set to “full duplex, 100 Mbps”: < 0.1Mbps! Specific combo of switch and adapter caused this performance degradation! Lesson: Check specs & configuration! Network adapter set to “autonegotiate”: 90Mbps
  48. 48. Agenda What sorts of stats are useful? How does vSphere retrieve them? How can you get these stats and use them yourself?
  49. 49. Stats infrastructure in vSphere ESX VM VM VM VM VM vCenter Server (vpxd, tomcat) ESX VM VM VM VM VM ESX VM VM VM VM VM DB 1. Collect 20s and 5-min host and VM stats 2. Send 5-min stats to vCenter 3. Send 5-min stats to DB 4. Rollups
  50. 50. Rollups DB 1. Past-Day (5-minutes) Past-Week 2. Past-Week (30-minutes) Past-Month 3. Past-Month (2-hours) Past-Year 4. (Past-Year = 1 data point per day) DB only archives historical data • Real-time (i.e., Past hour) NOT archived at DB • Past-day, Past-week, etc. Stats Interval • Stats Levels ONLY APPLY TO HISTORICAL DATA
  51. 51. Anatomy of a stats query: Past-hour (“RealTime”) Stats Client ESX VM VM VM VM VM vCenter Server (vpxd, tomcat) ESX VM VM VM VM VM ESX VM VM VM VM VM DB 1. Query 2. Get stats from host 3. Response No calls to DB Note: Same code path for past-day stats within last 30 minutes
  52. 52. Anatomy of a stats query: Archived stats Client ESX VM VM VM VM VM vCenter Server (vpxd, tomcat) ESX VM VM VM VM VM ESX VM VM VM VM VM DB 1. Query 3. Response No calls to ESX host (caveats apply) Stats Level = Store this stat in the DB 2. Get Stats
  53. 53. Agenda What sorts of stats are useful? How does vSphere retrieve them? How can you get these stats and use them yourself?
  54. 54. Phew! Ok, How do I get these stats? You want a chart like this? PowerCLI • CPU Usage for a VM for last hour: • $vm = Get-VM –Name “Foo” • Get-Stat –Entity $vm –Realtime –Maxsample 180 –Stat cpu.usagemhz.average • Grab appropriate fields from output, use graphing program, etc.
  55. 55. Looks simple… What’s going on behind the scenes? To get stats, this is what is going on FOR EACH GET-STAT CALL • Retrieve PerformanceManager • QueryPerfProviderSummary $vm Says what intervals are supported • QueryAvailablePerfMetric $vm Describes available metrics • QueryPerfCounter Verbose description of counters • Create PerfQuerySpec Query specification to get the stats • QueryPerf Get stats Bottom line: The PowerCLI toolkit spares you details…Easy to use!
  56. 56. PowerCLI Is so easy… Why use Java / C#? PowerCLI is great for scripting • Stateless • Hides details But with Java / C# • You can squeeze out more performance! • Much higher scalability
  57. 57. Pseudo code Get MOREF for each Get-Stat { QueryAvailablePerfMetric(); QueryPerfCounter(); QueryPerfProviderSummary(); create PerfQuerySpec(); QueryPerf(); } Get MOREF QueryAvailablePerfMetric(); QueryPerfCounter(); QueryPerfProviderSummary(); create PerfQuerySpec(); for each Get-Stat { QueryPerf(); } PowerCLI Java perfCounter property Of PerformanceManager
  58. 58. Performance implications: Need to write scalable scripts! Entities (cpu.usagemhz.average) PowerCLI (Time in secs) Java (Time in secs) 1 VM 9.2 14 6 VMs 11 14.5 39 VMs 101 16 363 VMs 2580 (43 minutes) 50 Java provides opportunities for scalable, ongoing stats collection Let’s examine Java code in more detail… A Naïve script that works for small environments may not be suitable for large environments Highly-tuned Java Stats Collector
  59. 59. GetPerfStats – Main method Get MOREF Get CounterIds QueryAvailablePerfMetric QueryProviderSummary create PerfQuerySpec QueryPerf Get MOREF QueryAvailablePerfMetric(); QueryPerfCounter(); QueryPerfProviderSummary(); create PerfQuerySpec(); for each Get-Stat { QueryPerf(); } perfCounter
  60. 60. GetPerfStats Get MOREF QueryAvailablePerfMetric(); QueryPerfCounter(); QueryPerfProviderSummary(); create PerfQuerySpec(); for each Get-Stat { QueryPerf(); }
  61. 61. Get MOREF Get the entity MOREF
  62. 62. GetPerfStats Get MOREF QueryAvailablePerfMetric(); QueryPerfCounter(); QueryPerfProviderSummary(); create PerfQuerySpec(); for each Get-Stat { QueryPerf(); } perfCounter property Of PerformanceManager
  63. 63. Get CounterIds Get available counterIDs from perfCounter property of PerformanceManager Map human-readable stat name to counterID (e.g., cpu.usagemhz.average 101) QueryPerf (…) requires counterID
  64. 64. GetPerfStats Get MOREF QueryAvailablePerfMetric(); QueryPerfCounter(); QueryPerfProviderSummary(); create PerfQuerySpec(); for each Get-Stat { QueryPerf(); }
  65. 65. QueryPerfProviderSummary • All VMs have same value • All Hosts have same value etc. Call once for a given entity type and store result
  66. 66. GetPerfStats Get MOREF QueryAvailablePerfMetric(); QueryPerfCounter(); QueryPerfProviderSummary(); create PerfQuerySpec(); for each Get-Stat { QueryPerf(); }
  67. 67. Create PerfQuerySpec Use wild card CSV output format
  68. 68. GetPerfStats Get MOREF QueryAvailablePerfMetric(); QueryPerfCounter(); QueryPerfProviderSummary(); create PerfQuerySpec(); for each Get-Stat { QueryPerf(); }
  69. 69. QueryPerf
  70. 70. So, what is Java / C# buying us? Avoiding redundant work More compact return format (CSV vs. objects) Low-overhead tracking of ongoing inventory changes Etc. If we dig deeper, we can optimize even more…
  71. 71. Digging deeper: The PerfQuerySpec architecture To grab counters: QueryPerf(PerfQuerySpec[] querySpec) PerfQuerySpec: Specifies which counters to grab PerfQuerySpec[]: [pQs1, pQs2, pQs3, …] Array of PerfQuerySpec objects pQs1, pQs2, pQs2 Can grab multiple stats using single QueryPerf call Entity (host, VM) Format (CSV, normal) MetricId StartTime EndTime IntervalID (20s, 300s) maxSample
  72. 72. Complexities of QueryPerf How Does vSphere Process QueryPerf(querySpec[])? 1. vCenter receives queryPerf request with querySpec[] 2. vCenter takes each querySpec one at a time 3. vCenter gets data for each querySpec before processing next one Options for querySpec[]: 1. 1 entry 1 stat or set of stats for a single entity (e.g., all CPU) 2. Multiple entries. Examples: • Each entry for a different entity … • Each entry for a different stat type, same entity VM1,cpu.* VM2,cpu.* H3,mem.* VM1,cpu.* VM1,net.* VM1,mem. * pQs1 pQs2 pQs3
  73. 73. Implications of QuerySpec Format of QuerySpec Allows Multiple Client Options 1. Grab each stat one at a time 2. Grab a group of stats per entity at once 3. Grab all stats for all entities at once 4. Grab stats for a subset of entities at once Some Tradeoffs: 1. Network processing (large result sets vs. small result sets) 2. Client aggregation overhead 3. vCenter processing (Each QueryPerf handled in a single thread)
  74. 74. What about in-guest stats? Using VIX APIs: • Create a script that can get what ever stats you are interested in. • Make the script write the stats to a file. • Copy file from the guest. • Session covering this topic • PPC-15 – Guest Operations using VMware VIX APIs and Beyond
  75. 75. Back to the Future (1) Now I know how to I convert this… (many metrics on different charts)
  76. 76. Back to the Future (2) To This (CPU, Memory, Disk, and Network on the same chart)
  77. 77. Combining metrics across VMs & Hosts
  78. 78. Combining metrics across VMs & Hosts
  79. 79. Comparing resource pools Use VIX API + vSphere counters to get RP performance data
  80. 80. What about VMs running on a Host? Memory usage of VMs on a Host
  81. 81. Summary, Part 1: Some useful Counters to monitor Resource Metric Host or VM? Description CPU Usage Both CPU % used Ready VM Ready to run, but limit or no available physical CPU SwapWait VM CPU time spent waiting for host-level swap-in Memory Swapin, swapinrate Both Memory ESX host swaps in from disk (per VM, or cumulative over host) Swapout, swapoutrate Both Memory ESX host swaps out to disk (per VM, or cumulative over host) Disk commands Both Operations done during stats refresh interval totalLatency Host End-to-end disk latency (available for reads & writes) Usage Both Disk bandwidth utilized (available for reads & writes) Network Packets received, transmitted Both Operations done during stats refresh interval Usage Both Network bandwidth used (available for reads & writes)
  82. 82. For completeness…VM memory metrics Metric Description Memory Active (KB) Physical pages touched recently by a virtual machine Memory Usage (%) Active memory / configured memory Memory Consumed (KB) Machine memory mapped to a virtual machine, including its portion of shared pages. Does NOT include overhead memory. Memory Granted (KB) VM physical pages backed by machine memory. May be less than configured memory. Includes shared pages. Does NOT include overhead memory. Memory Shared (KB) Physical pages shared with other virtual machines Memory Balloon (KB) Physical memory ballooned from a virtual machine Memory Swapped (KB) Physical memory in swap file (approx. “swap out – swap in”). Swap out and Swap in are cumulative. Overhead Memory (KB) Machine pages used for virtualization
  83. 83. Host memory metrics Metric Description Memory Active (KB) Physical pages touched recently by the host Memory Usage (%)* Active memory / configured memory Memory Consumed (KB) Total host physical memory – free memory on host. Includes Overhead and Service Console memory. Memory Granted (KB) Sum of memory granted to all running virtual machines. Does NOT include overhead memory. Memory Shared (KB) Sum of memory shared for all running VMs Shared common (KB) Total machine pages used by shared pages Memory Balloon (KB) Machine pages ballooned from virtual machines Memory Swap Used (KB) Physical memory in swap files (approx. “swap out – swap in”). Swap out and Swap in are cumulative. Overhead Memory (KB) Machine pages used for virtualization *For a cluster, mem.usage.average = (consumed + overhead)/total mem
  84. 84. Summary, Part 2: Cheat sheet Rules of Thumb • Ready Time > 20% sustained is undesirable • Host-level swapping is bad, > 1MBps is especially bad • Disk latencies > 20 ms BAD • Use IOmeter to assess disk bandwidth and latency • Network • run netperf to get network baselines
  85. 85. Summary, Part 3: SDK/API Tips and tricks Collect static data once • CounterIDs, metricIDs, MOREFs etc. • Use Views to keep this data up to date. • Reuse PerfQuerySpec as much as possible Use CSV format • Reduces serialization cost and the size of metadata Choose metrics and query intervals carefully • Query the real-time stats at a slower rate than the refresh rate • Choose correct stats levels Use parallelism (multi-threaded clients)
  86. 86. Conclusion vSphere gives a bunch of awesome charts If you want to see the data differently, use the API PowerCLI is great for simple scripts When designing for scalability, consider Java / C#
  87. 87. Resources Developer Support • Dedicated support for your organization when building solutions using vSphere APIs, PowerCLI, vSphere Web Services SDKs and many more VMware SDKs • http://vmware.com/go/sdksupport PowerCLI Training • 2 day instructor led training, 40% lecture, 60% lab • http://vmware.com/go/vsphereautomation VMware Developer Community • SDK Downloads, Documentation, Sample Code, Forums, Blogs • http://developer.vmware.com Technology Alliance Partner (TAP) Program • Updated partner benefits • http://www.vmware.com/partners/alliances/programs/
  88. 88. Disclaimer This session may contain product features that are currently under development. This session/overview of the new technology represents no commitment from VMware to deliver these features in any generally available product. Features are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind. Technical feasibility and market demand will affect final delivery. Pricing and packaging for any new technologies or features discussed or presented have not been determined. “These features are representative of feature areas under development. Feature commitments are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind. Technical feasibility and market demand will affect final delivery.”
  89. 89. Backup slides
  90. 90. What about VMs across resource pools?
  91. 91. Back to the Future (2) To This (CPU, Memory, Disk, and Network on the same chart)
  92. 92. Combining metrics across VMs & Hosts

×