When we provision CPU resources, which is the number of vCPUs allocated to run the VMs, and if its number is greater than the number of physical cores on a host, it is called CPU overcommitment. CPU overcommitment is a normal practice in many situations as it increases the consolidation ratio. Nevertheless, you need to monitor it closely.
CPU overcommitment is not recommended in order to satisfy or guarantee the workload of a tier-1 application with a tight SLA. It may be successfully leveraged to highly consolidate and reduce the power consumption of light workloads on modern, multicore systems.
To step through this recipe, you need a running ESXi Server with SSH enabled, a couple of running CPU-hungry VMs, an SSH client (Putty), a vCenter Server, and vSphere Web Client. No other prerequisites are required.
The following table elaborates on Esxtop CPU Performance Metrics:
Esxtop Metric | Description | Implication |
| The percentage of time a vCPU in a run queue is waiting for the CPU scheduler to let it run on a physical CPU. | A high |
| The percentage of possible CPU processing cycles that were actually used for work during this time interval. | The |
To spot CPU overcommitment, there are a few CPU resource parameters that you should monitor closely. They are:
- Log in to the ESXi Server using an SSH client (Putty).
- Type
esxtopand hit Enter.
- Monitor the preceding values to understand CPU overcommitment.
This example uses esxtop to detect CPU overcommitment. Looking at the pCPU line near the top of the screen, you can determine that this host's two CPUs are 100 percent utilized. Four active VMs are shown, Res-Hungry-1 to Res-Hungry-4. These VMs are active because they have relatively high values in the %USED column. The values in the %USED column alone do not necessarily indicate that the CPUs are overcommitted. In the %RDY column, you see that the three active VMs have relatively high values. High %RDY values plus high %USED values are a sure indicator that your CPU resources are overcommitted.
From the CPU view, navigate to a VM and press the E key to expand the view. It will give a detailed vCPU view for the VM. This is important because, at a quick level, CPU that is ready as a metric is best referenced when looking at performance concerns more broadly than a specific VM. If there is high ready percentage noted, contention could be an issue, particularly if other VMs show high utilization when more vCPUs than physical cores are present. In that case, other VMs could lead to high ready time on a low idle VM. So, long story short, if the CPU ready time is high on VMs on a host, it's time to verify that no other VMs are seeing performance issues.
You can also use the vCenter performance chart to spot CPU overcommitment, as follows:
- Log in to the vCenter Server using vSphere Web Client.
- On the home screen, navigate to
Hosts and Clusters. - Expand the left-hand navigation list.
- Navigate to one of the ESXi hosts.
- Navigate to the
Monitortab. - Navigate to the
Performancetab. - Navigate to the
Advancedview. - Click on
Chart Options. - Navigate to
CPUfromChart metrics. - Select only
UsedandReadyin theCounterssection and click onOK:
Now you will see the ready time and the used time in the graph and you can spot the overcommitment. The following screenshot is an example output:
The following example shows that the host has high ready time:
Although high ready time typically signifies CPU contention, the condition does not always warrant corrective action. If the value of ready time is also accompanied by high used time, then it might signify that the host is overcommitted.
So the used time and ready time of a host might signal contention. However, the host might not be overcommitted due to workload availability.
There might be periods of activity and periods that are idle. So the CPU is not over-committed all the time. Another very common source of high ready time for VMs, even when pCPU utilization is low, is due to storage being slow. A vCPU, which occupies a pCPU, can issue a storage I/O and then sit in the WAIT state on the pCPU, blocking other vCPUs. Other vCPUs accumulate ready time; this vCPU and pCPU accumulate wait time (which is not part of the used or utilized time).