Skip to main content

Posts

Showing posts from 2018

Interpreting Windows performance gathered from VMware and Hyper-V Guest Machines

In this blog entry, I want to step back and revisit a topic I have blogged about much earlier ( see  https://performancebydesign.blogspot.com/search/label/VMware . ) and discuss how guest machine performance counters are impacted by virtualization in general. Based on those impacts, we can assess which performance measurements guest machines produce remain viable for diagnosing performance problems and understanding capacity issues. Depending on the type of performance counter, the impact of the virtualization environment varies considerably. To begin, it is necessary to understand how both Hyper-V and the VMware ESX hypervisor affect the clocks and timers that are available on their guest machines. Essentially, Hyper-V intercepts all calls made from the guest OS to access hardware-based clock and timer services on the Host machine and substitutes a virtualized Time of Day clock value. The hypervisor takes pains to ensure that this virtual clock value sent to the guest is minimally

Understanding Guest Machine CPU Priority Scheduling options under Hyper-V

CPU Priority scheduling options. In a final set of benchmark results on Guest machine performance when the physical CPUs on the Hyper-V Host are over-committed, we will look now at how effective the Hyper-V processor scheduling priority settings are at insulating preferred guest machines from the performance impact of an under-provisioned (or over-committed) Hyper-V Host machine. The results of two test scenarios where CPU Priority scheduling options were used are compared to the over-committed baseline (and the original native Windows baseline) are reported in the following table: Configuration # guest machines CPUs per machine Best case elapsed time stretch factor Native machine … 4 90 … 4 Guest machines (no priority) 4 2 370 4.08 4 Guests using Relative Weights 4 2 230 2.56 4 Guest using Reservations 4 2 270 3.00 Table

Understanding Guest Machine Performance under Hyper-V: more benchmarks

Recognizing an under-provisioned guest machine Another set of benchmark results document the additional performance delays guest machines encounter when they execute on under-provisioned guest machines. I simulated this condition by executing the same benchmark on a guest Windows VM that had access to only two of the 4 available physical processors. Configured to use only two virtual processors, the benchmark program required 147 minutes to run to completion. Obviously, in this scenario the performance of the benchmark workload being executed on the 2-way guest machine suffered because it did not have access to an adequate number of virtual processors. It is easy to see that this guest machine is under-provisioned in this example where the conditions are tightly controlled. The key is being able to recognize when guest machines that are executing an unknown workload are under-provisioned. Look for the combination of the following: Each of the Hyper-V virtual processors allotted