VMware ESXi and vSphere Cluster Management

Monitor Active Memory Utilization in VMware ESXi

Learn how to use vCenter Server Advanced Performance charts to monitor host and per-VM active memory, recognize memory activity patterns, and correlate them with contention indicators.

Active memory is a useful vSphere performance metric for understanding which workloads are using physical memory at a given time. It is especially valuable when you need to move from a host-wide observation to a per-virtual-machine investigation.

This lesson shows how to configure an Advanced Performance chart in vCenter Server, select the host and relevant virtual machines, and interpret a stacked Active memory graph. It also explains why active memory must be correlated with capacity, reclamation, CPU, storage, and application indicators before you conclude that a memory shortage exists.

What active memory means

Active memory is the physical memory currently being actively used by virtual machines and VMkernel activity. The VMkernel is the ESXi hypervisor kernel and its host-level services. In vSphere memory performance charts, Active is the counter that represents this activity-oriented view of memory use.

Active memory describes recent working-set activity, not simply how much memory has been assigned or allocated. A VM can have a large configured memory size while actively using only part of it. Conversely, a VM with a modest configured size may actively use most of its allocation during a busy workload.

TermMeaningHow it differs from active memory
Configured memoryThe memory size assigned to a VM in its virtual hardware settings.It is an allocation limit or configuration value, not a measurement of current activity.
Consumed memoryMemory accounted for as consumed by a VM or host according to vSphere accounting rules.It can include memory that is allocated or retained but is not currently active.
Granted memoryMemory that ESXi has granted to a VM.Granted memory indicates provisioned physical backing, while Active indicates current activity.
Memory usage percentageA percentage calculated from a particular memory capacity or accounting context.The denominator matters; a percentage is not interchangeable with an Active counter.
Active memoryPhysical memory actively used by VMs and VMkernel activity.It is an activity signal and does not by itself prove that the host is out of memory.

A high Active value therefore does not automatically mean that the host is exhausted. A host can have high active use and still have enough readily available capacity with no significant reclamation. Conversely, contention can occur when demand exceeds available capacity even if a single metric does not appear extreme.

Why monitor active memory

Monitoring Active memory helps answer two practical questions:

  • Which workloads account for a large share of the host's current memory activity?
  • Is a change in application behavior associated with a change in memory demand?

Sustained high active memory for an individual VM identifies a workload that is more likely to encounter memory pressure when host capacity becomes limited. Per-VM visibility also prevents a host total from hiding the fact that one or two VMs dominate the current activity.

High active memory alone is not a memory-bottleneck diagnosis. Treat it as a signal for investigation. Confirm the host's available capacity and check ballooning, compression, swapping, and other reclamation indicators. Also check CPU and storage metrics when users report slowness.

Prerequisites, history, and access

  • An ESXi host managed by vCenter Server.
  • Access to the vSphere client inventory.
  • Permission to open host and VM performance-monitoring views.
  • Running, connected VMs with performance data available for the selected interval.

Available counters, history granularity, and retention depend on vCenter Server statistics settings and your permissions. A real-time chart is normally more granular but covers a shorter period. Longer historical views use collected and aggregated samples, so a short spike may not appear with the same shape or height.

Open the host Advanced Performance chart

  1. In the vSphere client, select the target ESXi host in the inventory.
  2. Open the Monitor area.
  3. Select Performance.
  4. Open the Advanced chart view.
  5. Open chart configuration or chart options before choosing the counters.

Labels and their arrangement can vary slightly between vSphere client versions. Look for the same functional elements: a host performance view, an Advanced chart, a metric group, a time range, a chart layout, object selection, and counters.

Configure a per-VM Active memory chart

Chart settingRecommended selectionPurpose
Inventory objectTarget ESXi hostProvides the host context for the comparison.
Monitoring viewMonitor > Performance > AdvancedExposes detailed object and counter choices.
Metric groupMemoryDisplays memory-related counters.
Time rangeReal-timeShows current activity using relatively granular samples.
Chart typeStacked graph grouped per virtual machineShows the combined selected activity and each object's contribution.
ObjectsThe selected host and relevant running VMsAllows host and per-VM activity to be compared.
CounterActiveDisplays physical memory activity rather than only configured allocation.

Configure the chart as follows:

  1. Choose Memory as the metric group.
  2. Select Real-time for current operational monitoring.
  3. Choose a stacked graph or the equivalent per-VM stacked layout.
  4. Include the host and the relevant virtual machines in the chart objects. Include all running VMs when the purpose is to identify the largest contributors.
  5. Select the Active counter.
  6. Apply the configuration and allow enough samples to appear before drawing conclusions.
Inventory object: target ESXi host
Navigation: Monitor > Performance > Advanced
Metric group: Memory
Time range: Real-time
Chart type: Stacked graph, grouped per virtual machine
Objects: selected host and relevant virtual machines
Counter: Active

How to read the stacked graph

The host-level series provides the host context. Individual VM series show how selected virtual machines contribute to the displayed activity. In a stacked graph, values are layered: the aggregate visual height represents the cumulative activity of the selected series, while each color or segment identifies one contributing object.

Do not interpret the top edge of a stacked area as the Active value of the VM represented by the top color. To understand one VM's contribution, compare the boundaries of its segment or use the legend and the chart's displayed values.

Look for these patterns:

  • Sustained elevated values: activity remains high over a meaningful workload interval rather than appearing in one sample.
  • Abrupt step changes: a VM or several VMs begin using substantially more memory at a particular timestamp.
  • Recurring peaks: activity rises at regular times, often matching reports, batch jobs, backups, patching, or scheduled maintenance.
  • A dominant segment: a small number of VMs account for most of the stacked activity.

Use timestamps to compare the chart with workload schedules and operational events. A rise that begins when a reporting job starts may be expected. A rise that persists after the job ends may require application or capacity investigation.

Interpret high Active memory safely

Evaluate Active memory against several forms of context:

  • The physical RAM installed in the host and the capacity currently available to workloads.
  • Configured memory and observed activity for each VM.
  • The normal baseline for the same workload during a known healthy period.
  • Host memory usage or consumed memory.
  • Ballooning, compression, swapping, and other reclamation indicators.

An individual VM with persistently high Active memory may need application-level review, right-sizing analysis, or placement evaluation. Right-sizing means adjusting a VM's resource allocation to better match its observed workload needs. Do not automatically increase every VM's assigned memory merely because its Active counter is high. Additional allocation can increase contention elsewhere and may not fix an application or storage problem.

Metric or indicatorWhat it representsWhat a high value can suggestWhat to check next
Active memoryCurrent physical memory activity from VMs and VMkernel activity.An active or memory-intensive workload.Workload baseline, host capacity, and reclamation counters.
Host memory usage or consumed memoryHost-level memory accounting and capacity use.Less readily available capacity, depending on the accounting context.Physical RAM, reservations, shares, overhead, and available capacity.
BallooningReclamation through the VMware balloon driver, which asks a guest OS to release memory.ESXi is attempting to reclaim memory from guests.Host pressure, VM activity, and guest performance.
Memory compressionPages compressed by ESXi before swapping is needed.Memory reclamation is active or capacity is becoming constrained.Compression trend, available capacity, and swapping.
Host swappingESXi moves VM memory pages to a host swap file.More serious memory pressure and possible performance degradation.Swap activity, datastore latency, VM performance, and host capacity.
Guest swapping, if availableThe guest operating system is paging or swapping its own memory.The guest may be under memory pressure, independently of ESXi reclamation.Guest memory, processes, application behavior, and host indicators.

Correlate Active memory with contention indicators

Memory contention occurs when host memory demand exceeds readily available physical capacity. Active memory describes demand and activity; ballooning, compression, and swapping describe responses used to reclaim memory. These are related but different measurements.

  1. Check host memory usage and physical capacity context.
  2. Review ballooning, memory compression, host swapping, and other available reclamation counters.
  3. Check guest swapping when the guest operating system exposes that information.
  4. Review CPU ready time and other CPU contention indicators. CPU pressure can affect application behavior and lead to an incorrect memory diagnosis.
  5. Review datastore and disk latency if application slowness could be storage-related.
  6. Compare all metrics over the same time range and, where possible, the same sampling interval.

High Active memory with no reclamation and normal application performance may simply be a healthy workload baseline. High Active memory combined with ballooning, compression, swapping, or degraded application performance is stronger evidence that capacity or placement deserves attention.

Operational response workflow

  1. Establish a baseline. Record Active memory during known healthy periods, including normal peak periods.
  2. Identify affected VMs. Use the stacked chart to find the segments responsible for the increase.
  3. Classify the change. Determine whether it is expected, scheduled, temporary, recurring, or persistent.
  4. Validate capacity and contention. Check host capacity and reclamation before changing VM allocations.
  5. Choose a targeted response. Depending on the evidence, consider VM right-sizing, workload scheduling, vMotion or DRS placement, host capacity expansion, or application investigation.
  6. Recheck after the change. Use the same object selection and time range when comparing before-and-after results, and review related counters again.

Practical examples

Identify a VM dominating host active memory

  1. Open the selected host's Advanced Performance chart.
  2. Configure a real-time Memory chart with a per-VM stacked layout.
  3. Select the host and all running VMs, then enable the Active counter.
  4. Identify the VM whose segment consistently represents the largest portion of the stack.
  5. Compare that VM's activity with its normal schedule and inspect memory contention counters before making a change.

The result is a contributor-level diagnosis instead of reliance on a host total alone.

Investigate a sudden memory activity increase

  1. Find the timestamp at which the Active chart rises sharply.
  2. Determine which VM series changed at that time.
  3. Check for scheduled application jobs, reporting tasks, backup activity, patching, or workload deployment events.
  4. Review host capacity and reclamation counters over the same interval.

This helps classify the rise as expected workload behavior or an event requiring capacity or application investigation.

Decide whether high Active memory is urgent

  1. Observe the VM with high, sustained Active memory.
  2. Verify whether the host also shows ballooning, compression, swapping, or poor application performance.
  3. If contention indicators are absent and performance is normal, record the value as a baseline and continue monitoring.
  4. If contention or degradation is present, evaluate placement, capacity, VM sizing, and application behavior.

Troubleshooting chart and interpretation problems

The Active counter is not visible

Confirm that Memory is the selected metric group and that the selected object is an ESXi host with relevant VMs included. Try the Advanced Performance configuration view. If the counter remains unavailable, review vCenter permissions and statistics collection settings.

The chart does not show individual VM contributions

Only the host may be selected, or the chart may use a non-stacked layout. Add the intended virtual machines, choose a stacked per-VM layout, and confirm that the VMs are powered on, connected, and providing performance data.

Active memory is high but users report no performance issue

The workload may legitimately be active and the host may still have sufficient capacity. Compare the value with a healthy baseline, review ballooning, compression, swapping, and capacity, and continue monitoring rather than resizing solely from the Active metric.

High Active memory coincides with VM slowness

Check ballooning, compression, swapping, and host capacity. Then check CPU contention and datastore or disk latency over the same period. The root cause may be memory contention, CPU pressure, storage latency, or an application issue.

Limitations and cautions

  • Do not diagnose a memory shortage solely from a high Active memory line.
  • Do not compare a short real-time spike directly with a long-term historical average without accounting for sampling interval and aggregation.
  • Use the same selected objects and time range for before-and-after comparisons.
  • Powered-off, disconnected, or inaccessible VMs may not provide useful current performance data.
  • A stacked chart shows cumulative selected activity; it is not automatically a direct measurement of remaining host capacity.

Exam-relevant notes

  • Active memory is an activity-oriented counter, not the same as configured, granted, consumed, or percentage usage.
  • High Active memory does not by itself prove memory contention.
  • Ballooning, compression, and swapping are reclamation or pressure indicators that should be correlated with Active memory.
  • A per-VM stacked chart helps identify which workloads contribute most to host memory activity.
  • CPU contention and storage latency can produce performance symptoms that resemble memory problems.

For broader VMware administration study, see the VMware ESXi online course. When memory-related symptoms overlap with storage behavior, review the relevant ESXi disk usage and storage latency material if available in your course navigation.