CPU load is generated by the guest and its applications as well ESX Server as it provides a virtual interface to the hardware. While the work performed by the host does result in some increase in load, the great majority of processing is due to the applications in the VM. A solid understanding of the workload profile regardless of the virtual environment can assist CPU analysis.
Invoke esxtop. By default, it should show CPU utilization but pressing ‘c' will ensure this data is being displayed. The following figure shows example data produced on a test system.
Observe the following:
The general flow for evaluation starts by considering the system's load. Is the system overloaded with too many VMs? Is the guest using all of its vCPUs and simply requires more or faster processors? Are all guests waiting for IO? For example:
As stated above, both the PCPU(%) and %USED counters can be used to identify systems hosts that are using all physical CPUs. It is possible, however, for the VMs on the system to be utilized nearly all of the processor cycles without actually requesting more that is available. This near-saturation case is the sign of a heavily loaded system.
A better sign of over-utilization on a host is ready time (%RDY). When any world's ready time starts to climb, that world is spending the reported percentage of its time waiting for some CPU to become available for work. Ready time above 10% is worth investigation and may be a sign of an over-utilized host. For a more detailed discussion on ready time, see Ready Time.
Host saturation is a clear sign that too much work has been loaded onto a single server. This is usually due to overly aggressive consolidation ratios. Overcommiting CPU resources in this case will only worsen the performance. Consider the following remedies:
The easiest general comment for addressing CPU bottlenecks given correctly-configured VMs is to address processing power at the cluster level. If VirtualCenter reports fully utilized CPUs for all hosts in the cluster, there is little possibility of avoiding a need to increase cluster resources or decrease VM count.
One last nuance of virtual system tuning, mentioned in item 6c above, is the correct balancing of virtual CPU count. Few applications fully utilize two or more vCPUs and many VMs are often committed to a special purpose with a single application. The guest OS and the hypervisor must expend CPU cycles managing multiple vCPUs. If the applications are not using them, the system efficiency as a whole will improve by reducing vCPU count for VMs.
Like host CPU saturation, VM CPU saturation can be seen when the %USED for a VM is high. Unlike host CPU saturation, the idle world may report a large amount of free computational resources and the VM's ready time (%RDY) may remain low. This behavior can be seen when a single VM utilizes all of the processors allocated to it but additional CPUs remain unused on the host. The VM's utilization of all of its vCPUs can be confirmed by expanding the VM's world on the CPU screen. Once this has been confirmed, the following options are available:
Assuming performance problems have been confirmed, low CPU utilization is usually a sign of inefficiently designed datacenter architecture. The design could be flawed in an individual VM or in the connectivity between various components. The Performance Monitoring and Analysis will walk through investigation of system-level components such as memory and then system-wide components such as network and storage.