ESXi host CPU usage appears high in vCenter default charts due to Turbo Boost and Hyperthreading counter behavior
search cancel

ESXi host CPU usage appears high in vCenter default charts due to Turbo Boost and Hyperthreading counter behavior

book

Article ID: 431027

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

  • vCenter shows ESXi host CPU usage near or above 80-100% on the default host performance chart, but VMs show no signs of CPU contention.
  • VM %Ready values are consistently low (below 2-3%) and %CoStop is at or near 0%.
  • The host appears to have capacity problems based on the default vCenter CPU chart, but VM performance is not impacted.
  • You need to determine actual host CPU capacity for planning purposes, but the default vCenter metric does not reflect real scheduling demand.

Additional symptoms reported:

  • "Why are the hosts consistently reporting CPU usage near 100% despite no contention?"
  • "How do I know my actual CPU capacity for planning?"
  • vCenter CPU usage values appear inconsistent with observed VM performance.

Environment

  • ESXi hosts with Intel Turbo Boost or AMD Precision Boost enabled
  • ESXi hosts with Hyperthreading (HT) enabled
  • vCenter Server with default Statistics Level 1 collection

Cause

vCenter's default host CPU performance chart uses the cpu.usage.average counter. This counter overstates actual host capacity consumption due to two factors:

Turbo Boost frequency scaling

The cpu.usage counter is frequency-based. It measures CPU time in timer cycles rather than wall-clock time. When processor cores run above their base frequency due to Turbo Boost, the counter registers more cycles per second than the base frequency accounts for. This inflates the reported value even when logical CPU threads are idle.

For example, on a host with a 2.80 GHz base frequency and 3.50 GHz turbo, a fully busy core reports approximately 125% usage rather than 100%. This inflation scales with the degree of turbo activity across all cores. In practice, this factor alone can add 4-12% or more to the reported host CPU usage value.

Hyperthreading accounting

The cpu.usage counter at the ESXi host level does not properly distinguish between physical cores and logical threads. It rolls up logical CPU busy time in a way that reflects physical core saturation rather than logical thread availability. On hosts with Hyperthreading enabled, this further inflates the reported value.

The combined effect of these two factors can cause cpu.usage to report 75-85% or higher while actual thread-level scheduling demand is only 38-55%. Both numbers are valid measurements, but they measure different things. Only the time-based counter accurately reflects remaining host scheduling capacity.

A different counter, cpu.utilization, measures time-based scheduling demand on logical CPUs. It is not affected by Turbo Boost frequency and accounts for Hyperthreading correctly. This counter answers the capacity question: "What percentage of my logical CPU threads are busy?"

The cpu.utilization counter requires Statistics Level 2 in vCenter. The default Statistics Level 1 only collects cpu.usage. This means most vCenter environments show the counter that overstates capacity consumption by default and do not show the one that accurately reflects it.

Resolution

Use the correct metric for capacity planning

Use cpu.utilization (%) instead of cpu.usage (%) for host CPU capacity assessment. In esxtop, the equivalent counter is % Processor Time (not % Used).

The cpu.utilization counter is time-based and Hyperthreading-aware. It is not inflated by Turbo Boost. When this counter approaches 100%, the host is running out of scheduling capacity.

Plan capacity against the processor's base frequency, not turbo. Turbo Boost availability depends on thermal conditions, power budget, and the number of active cores. As a host gets busier, turbo diminishes. The cpu.utilization counter handles this correctly because it does not factor in frequency.

Capacity thresholds:

Metric Source Threshold
Host CPU Utilization (%) cpu.utilization in vCenter or % Processor Time in esxtop Sustained above 70-80% warrants attention
VM CPU Ready (%) cpu.ready in vCenter or %RDY in esxtop (per vCPU) Above 5% = warning; above 10% = action needed
VM CPU CoStop (%) cpu.costop in vCenter or %CSTP in esxtop Any sustained value above 0% warrants review

 

Enable cpu.utilization in vCenter

The cpu.utilization counter is not collected at the default Statistics Level 1. Choose one of the following options to make it available:

Option A: Raise the statistics collection level

  1. Open the vSphere Client and connect to vCenter Server.
  2. Select the vCenter Server in the inventory.
  3. Navigate to Configure > General > Statistics.
  4. Click Edit.
  5. Change the statistics level for the desired collection interval(s) to Level 2.
  6. Click OK.

This enables all Level 2 counters. Database storage requirements increase modestly. Levels 1 and 2 are both suitable for normal production use.

Option B: Remap the single counter to Level 1

Use the LevelMappingUtility PowerCLI module to map the cpu.utilization counter to Level 1 without raising the full statistics level. This approach avoids the additional database load of a full Level 2 collection.

See Persisting vSphere metrics without increasing statistic levels for instructions.

View the correct metric in vCenter

After enabling the counter, build a custom chart:

  1. Select the ESXi host in the inventory.
  2. Navigate to Monitor > Performance > Advanced.
  3. Click Chart Options.
  4. Select CPU from the chart type dropdown.
  5. Add the Utilization counter.
  6. Save the chart view for reuse.

You can display Utilization alongside Usage to see both values. The gap between them on the same host at the same time is a rough indicator of how much Turbo Boost and Hyperthreading accounting inflate the default chart.

Use Aria Operations (if available)

VMware Aria Operations (formerly vRealize Operations) capacity and contention dashboards already account for Hyperthreading and frequency effects. The CPU Contention (%) metric in Aria Operations 8.18 and later is designed for this scenario.

For versions before 8.18, see VM CPU Contention metric change after upgrade to Aria Operations 8.18.x for details on how the contention calculation changed.

Confirm with esxtop

To verify host capacity directly from the ESXi command line:

  1. Connect to the ESXi host via SSH.
  2. Run esxtop.
  3. Press c to open the CPU panel.
  4. Observe %Processor Time in the host summary line. This is the time-based capacity metric.
  5. Compare it to %Used. The gap between them reflects Turbo Boost and Hyperthreading inflation.

To see the degree of Turbo Boost per physical core:

  1. In esxtop, press p to switch to the Power Management panel.
  2. Press f, then f again, then press Enter to add the %A/MPERF field.
  3. A value of 100 means the core runs at base frequency. Values above 100 indicate turbo activity. For example, 108 means 8% above base frequency.

Note: The %A/MPERF counter is only valid when the core is in C0 (active running) state. See Testing CPU max Turbo Boost frequency in ESXi for details.

Assess contention as a capacity signal

High utilization alone does not confirm a capacity problem. Contention metrics confirm whether VMs are actually affected:

  • %Ready measures the time a VM was ready to run but had to wait for a physical CPU. This is the primary indicator that a host is running out of CPU capacity. Values above 5% per vCPU indicate a real impact on VM performance.
  • %CoStop measures the time a multi-vCPU VM waited because the scheduler could not schedule all of its vCPUs together. Elevated %CoStop often indicates the VM has more vCPUs than its workload needs.

If cpu.utilization is high but %Ready and %CoStop are low across all VMs, the host still has effective capacity and VMs are not being impacted.

For more information on using %Ready, %CoStop, %Wait, and %Run together to assess VM CPU health, see Troubleshooting a virtual machine that has stopped responding: VMM and Guest CPU usage comparison.

Additional Information

Powered by Wolken Software