ESXTOP on ESXi: Find the Bottleneck Before You Guess

When a VM is slow, it is tempting to add vCPUs, reboot it, or blame the storage array. esxtop gives you a better first move: it shows what the ESXi host is doing at the moment the problem occurs.

Think of it as a live performance console for the VMkernel. It can show CPU scheduling, memory reclamation, storage I/O, and network traffic at host, device, and VM level. The point is not to memorize every column. The point is to use the right screen to answer a specific question.

Before you start

Connect to the affected ESXi host through the ESXi Shell or SSH and run:

esxtop

The display refreshes continuously. These keys are the useful starting kit:

The four questions esxtop answers

When somebody reports that a VM is slow, work through the resource types in this order:

1. Is the host short of CPU scheduling time?
2. Is ESXi reclaiming or swapping memory?
3. Is I/O slow at the ESXi kernel or storage-device layer?
4. Is a physical NIC saturated or dropping traffic?

This is useful because a storage or network symptom can be caused by CPU pressure first. For example, a VM may report a slow backup because its vCPU cannot get scheduled quickly enough, even when the datastore is healthy.

CPU: is the VM waiting to run?

Press c for the CPU view. Look at the host summary first, then find the VM or world with the problem.

%RDY is the counter most administrators look for first. Broadcom calls out keeping it below 5% under normal conditions. Treat that as a signal to investigate, not a magic line: compare it with the VM’s normal behaviour, the host load average, and whether the problem is sustained rather than a single refresh.

Example: A four-vCPU application VM has low %USED, but persistent high %RDY and %CSTP. Adding more vCPUs is unlikely to help. First check host contention, CPU limits, and whether the application truly needs four vCPUs. Reducing an oversized VM can make it easier for ESXi to schedule.

Memory: is ESXi reclaiming RAM?

Press m for memory. A host can have allocated more VM memory than physical RAM, but the important question is whether ESXi has started reclaiming it in a way that affects guests.

Use f to add memory reclamation fields, then look for:

Ballooning is not automatically an outage, but sustained ballooning means the host is under memory pressure. Host swapping is more serious because ESXi is moving VM memory to disk. If SWCUR is growing while VMs are slow, stop treating this as a CPU issue and reduce memory pressure: check limits, reservations, recent VM placement, and capacity.

Storage: locate the latency layer

Storage is where esxtop earns its keep. It lets you move from an affected VM to a virtual disk, device, LUN, or adapter without guessing where latency starts.

Use the views together:

Slow VM
  -> press v: is its virtual disk seeing latency or heavy I/O?
    -> press u: is the backing device or LUN also slow?
      -> press d: is the adapter under pressure too?

Enable and compare these fields in the disk views:

The relationship is more valuable than a single number:

High DAVG + low KAVG  -> the delay is likely beyond ESXi: device, fabric, or array
Low DAVG + high KAVG  -> investigate ESXi-side queuing and queue depths
High GAVG             -> confirms the VM is paying for the latency above

Broadcom’s storage guidance uses 10 ms as a useful sustained-latency investigation point for DAVG, KAVG, and GAVG; application needs and storage design still matter. A brief spike during a backup is different from latency that stays elevated while users are waiting.

For vSAN, the v view is especially useful to identify the VMs experiencing I/O pressure, but it is not a replacement for vSAN Health, resync status, and network checks. Pair the two: use esxtop to establish the symptom and scope, then use vSAN tooling to investigate the cluster cause.

Network: verify the path from the host

Press n to inspect network traffic. This view helps answer whether ESXi is moving the expected amount of traffic and whether packets are being dropped at a physical NIC.

Look for the pNIC that carries the relevant workload: management, vMotion, vSAN, or VM traffic. Compare throughput with its link speed and look closely at receive/transmit drop counters. Drops that rise during the incident deserve investigation in the switch, NIC driver/firmware, and ESXi configuration. They are evidence of a problem, not proof of the exact cause.

Before spending hours on a network theory, rule out CPU pressure. Broadcom notes that network performance can be strongly affected by CPU performance.

Capture an intermittent problem

Interactive esxtop only sees now. For a problem that appears during a backup, at month end, or after a scheduled job, use batch mode and collect a CSV for later analysis.

# Capture all counters every 2 seconds for 30 minutes (900 samples)
esxtop -b -a -d 2 -n 900 > /vmfs/volumes/DATASTORE/esxtop-incident.csv

-b enables batch mode, -a collects all metrics, -d is the interval in seconds, and -n is the number of samples. Write the file to a datastore with enough free space and avoid collecting onto the datastore you are trying to prove is already overloaded.

The CSV becomes useful when you line it up with events: backup start time, VM migration, storage alert, switch change, or the time users reported the slowdown. Look for the first counter that changes, not merely the counter that looks worst at the end.

A small incident workflow

Use this during the next “everything feels slow” ticket:

1. Note the affected VM, host, and exact time.
2. Run esxtop on that host and press c. Check load, %RDY, %CSTP, and %MLMTD.
3. Press m. Check for ballooning and host swapping.
4. Press v, then u and d if storage is involved. Compare DAVG, KAVG, and GAVG.
5. Press n if the workload crosses the network. Check relevant pNIC throughput and drops.
6. If the issue is gone before you arrive, run a bounded batch capture for the next window.

esxtop will not fix a bad array, an undersized host, or an oversized VM. What it does well is stop you from changing three things at once. It gives you a measured starting point for the next investigation.

Official references

• Using ESXTop and Interpreting ESXTop Statistics (Broadcom KB 382249)
• Using esxtop to identify storage performance issues for ESXi (Broadcom KB 344099)
• Performance Data Collection using esxtop and resxtop (Broadcom KB 308926)
• Troubleshooting ESX/ESXi virtual machine performance issues (Broadcom KB 304594)