VMware ESXi and vSphere Cluster Management

Monitor Active Memory Utilization in VMware vSphere

Learn how to use vCenter Server performance charts to monitor ESXi host and per-VM active memory, recognize memory pressure, and choose follow-up actions.

Active memory monitoring helps a vSphere administrator understand which workloads are using host memory and whether available capacity may be narrowing. This guide uses the vSphere Client performance-chart workflow to compare an ESXi host with its virtual machines.

Active memory is an estimate of memory actively used by a virtual machine or by VMkernel activity during a sampling period. It is useful for identifying workloads with sustained or changing memory demand, but it is not a complete diagnosis by itself. Always evaluate it with host capacity, consumed and granted memory, and memory-reclamation indicators.

Purpose of Active Memory Monitoring

An ESXi host is the VMware hypervisor system that provides compute and physical memory resources to virtual machines. The VMkernel is the ESXi kernel and its platform services; it also consumes host memory independently of guest VMs.

Active memory shows an estimate of the physical memory recently and actively used by workloads. A large or sustained value can help reveal:

  • Which VMs account for the greatest share of active memory on a host.
  • Whether aggregate workload activity is increasing over time.
  • Whether bursts coincide with application jobs, configuration changes, or VM placement changes.
  • Which VM deserves a more detailed performance review.

High active memory does not automatically mean that a VM or host is in trouble. A host can have high active use while retaining adequate physical-memory headroom. Conversely, a host can experience pressure even when a short real-time sample does not show an obvious spike. Treat active memory as a workload-activity signal and correlate it with capacity and reclamation metrics.

Scope and Prerequisites

The workflow below requires the ESXi host to be managed by vCenter Server. vCenter Server is the vSphere management platform that maintains inventory and provides performance reporting for managed hosts and VMs.

Before starting, confirm the following:

  • You can sign in to the vSphere Client connected to vCenter Server.
  • Your account has permission to view host and VM performance data.
  • You know which ESXi host is under investigation.
  • You have identified the VMs whose memory activity should be compared.
  • You understand the basic relationship between vCenter Server, the ESXi host, and VMs.

A performance chart is a vCenter visualization of collected counters over a selected time period. A real-time interval is a short, recent view intended for observing current or immediately recent behavior.

Open Advanced Host Performance Charts

  1. In the vSphere Client, open the vCenter inventory.
  2. Select the target ESXi host.
  3. Open Monitor.
  4. Choose Performance.
  5. Open the Advanced chart view.
  6. Open the chart configuration or chart-options control.

The exact visual placement of controls can vary between vSphere Client versions, but the required context is the selected host's advanced performance view.

Configure an Active Memory Chart

Configure the chart so that it displays memory activity for the host and its relevant VMs:

SettingRecommended SelectionPurpose
Metric categoryMemoryDisplays memory-related counters, including Active when available.
Time rangeReal-timeShows current or immediately recent behavior during an active investigation.
Graph typeStacked Graph (per VM)Separates VM contributions while showing their combined stack.
ObjectsThe ESXi host and relevant virtual machines on itProvides host context and per-VM comparison.
CounterActiveShows estimated actively used memory for the selected objects.
  1. Set the metric category to Memory.
  2. Select a Real-time interval when investigating current behavior.
  3. Choose Stacked Graph (per VM).
  4. Add the target ESXi host and the virtual machines that should be compared.
  5. Select the Active counter.
  6. Apply the configuration and inspect the chart over its time axis.

A stacked graph per VM separates selected VM values into stacked segments. Each segment represents one selected VM's active-memory contribution. The combined stack provides a view of aggregate active demand for the selected workload set, while the individual segments show which VMs contribute most.

Interpret the Stacked Per-VM Chart

Read individual segments

Look for the size and duration of each VM's segment. A large segment that remains high for an extended period is a candidate for further investigation. A brief, narrow increase may simply represent a normal workload burst.

  • Steady use: A relatively consistent segment may indicate a stable application working set.
  • Bursting: Repeated or isolated peaks may correspond to backups, reports, batch jobs, log processing, or other scheduled activity.
  • Step changes: A new sustained level may follow a workload increase, guest configuration change, application update, or VM migration.
  • Aggregate height: The total stack helps show how much active demand the selected VMs create together.

Do not interpret the selected VM stack as the entire host's memory requirement without qualification. VMkernel activity and other host-level demand also consume memory. Consider the host's capacity and host-level memory counters when assessing remaining headroom.

Compare activity over time

Compare the chart with a known normal period when possible. Ask whether the high value is sustained, whether only one VM drives the increase, and whether the timing matches a workload or configuration event. A real-time chart is useful for current observation, but intermittent incidents often require a longer historical interval.

Assess Memory-Constraint Risk

Sustained high aggregate active memory can indicate that host memory headroom is shrinking, especially when the workload approaches the host's usable physical capacity. A VM with persistently high active memory may require review of its configured memory size, application behavior, and host placement.

Correlate active memory with these metrics:

MetricWhat It IndicatesWhy It Matters During Investigation
Active memoryEstimated memory actively used during the sampling period.Identifies current workload activity and major VM contributors.
Consumed memoryMemory consumed from host resources by the VM or workload.Provides additional context about resource usage beyond the active working set.
Granted memoryMemory provided or presented to the VM.Helps compare configured or granted memory with what the workload is actively using.
BallooningMemory reclamation in which the guest operating system is asked to release memory.Nonzero or rising activity can indicate that the host is responding to memory pressure.
Memory compressionCompression of memory pages to reduce swapping during pressure.Indicates that ESXi is using a pressure-management technique.
Host swappingUse of disk-backed swap space when physical memory is insufficient.Typically signals significant pressure and can affect performance.

Memory contention is a condition in which memory demand creates pressure on available host memory resources. Active memory alone does not prove contention. Increasing ballooning, compression, or host swapping provides stronger evidence that the host is reclaiming memory or cannot satisfy demand without assistance.

Practical Investigation Examples

Find the VM contributing most to host active memory

  1. Select an ESXi host in vCenter Server.
  2. Configure an advanced Memory chart for a real-time period.
  3. Choose a stacked per-VM graph.
  4. Select the host, all relevant resident VMs, and the Active counter.
  5. Identify the largest sustained VM segment.
  6. Open that VM's performance view for deeper review.

This identifies which workloads account for the largest share of active host memory. It does not, by itself, establish that the VM is misconfigured or responsible for user impact.

Investigate a host with suspected memory pressure

  1. View the host's active-memory chart during the affected period.
  2. Determine whether aggregate activity is persistently high or spikes with a particular VM.
  3. Correlate the timing with ballooning, compression, swapping, and workload events.
  4. If one VM dominates, review that VM and its application behavior.
  5. If the whole host is affected, evaluate placement and host capacity.

This comparison helps distinguish an isolated workload contributor from broader host-capacity pressure.

Validate workload redistribution or right-sizing

  1. Record the active-memory profile before moving or reducing a workload.
  2. Make the planned placement or sizing change.
  3. Review the same chart afterward using a comparable interval.
  4. Confirm that aggregate host demand and the relevant VM contribution changed as expected.

Operational Follow-Up

When a large contributor is identified, review the individual VM's performance charts and determine whether the high activity is expected for its application. Check whether it is a recent change or a long-standing baseline.

Possible actions include:

  • Right-size VM memory when the configured allocation does not match the workload's requirements.
  • Investigate application memory growth, leaks, caches, or unusually large working sets.
  • Balance workloads across hosts when placement concentrates memory demand.
  • Add host capacity when demand is consistently greater than the available physical-memory budget.
  • Schedule or redesign burst-heavy operations when they create avoidable contention.

Use longer historical intervals when the incident is intermittent or outside the real-time retention window. Correlate chart timestamps with application schedules, VM migrations, configuration changes, and user reports.

Troubleshooting the Chart

The Active counter is not visible

Possible causes include an incorrect metric category, an object or chart context that does not expose the expected counters, or insufficient performance-view permissions.

  • Confirm that Memory is selected as the metric category.
  • Return to the host's Monitor > Performance > Advanced view.
  • Select the host and relevant VMs as chart objects.
  • Verify the vCenter connection status.
  • Ask an administrator to verify your performance-data permissions.

An expected VM is missing

The VM may no longer be running on that host, it may have been omitted from the selected objects, or the selected interval may not include the time it was resident there.

  • Confirm the VM's current host placement and power state.
  • Edit chart options and add the VM when applicable.
  • Select an interval covering the period under investigation.

Active memory is high, but user impact is unclear

High activity may be normal for the workload, the host may still have adequate physical-memory headroom, or the increase may be temporary.

  • Review ballooning, compression, and swapping counters.
  • Compare current values with a known normal baseline.
  • Examine a longer time range.
  • Correlate the increase with VM and application activity.

The real-time graph does not capture the incident

The event may have occurred outside the real-time retention window or may be intermittent. Select an appropriate historical interval if available, use recurring monitoring or alerts for future occurrences, and correlate timestamps with operational events and workload schedules.

Summary

  • Use vCenter Server advanced host performance charts to compare ESXi host and per-VM memory activity.
  • Configure Memory, Real-time, Stacked Graph (per VM), the host and relevant VMs, and the Active counter for current investigations.
  • Use segment size and duration to find major contributors and distinguish sustained demand from short bursts.
  • Assess host capacity and VMkernel demand alongside the selected VM stack.
  • Correlate active memory with consumed and granted memory, ballooning, compression, swapping, and contention indicators.
  • Follow up with VM-level analysis, workload redistribution, right-sizing, application investigation, or added host capacity as appropriate.

For a focused reference, return to monitoring active memory utilization in vSphere.