Windows Memory Metrics in Datadog

Docs > Metrics > Metrics Guides > Windows Memory Metrics in Datadog

Overview

Windows offers multiple memory metrics that serve different monitoring purposes—from tracking physical RAM usage to understanding virtual memory allocation and commit charges.

Use this guide to:

Understand the key differences between physical memory, virtual memory, commit charge, and commit limit
Identify which Datadog metrics correspond to specific Windows memory concepts
Find the equivalent metrics across Datadog’s monitoring tools and Windows native Performance Counters
Select the appropriate metrics for your specific monitoring needs

For additional context on Windows memory architecture, see Microsoft’s Memory Performance Information documentation.

Key terms

Physical Memory: Actual physical RAM that is in use. Sometimes also called the “working set” or RSS.
Commit charge: Total of all memory that must be backed by RAM or the paging files. Sometimes also called “private bytes”.
Commit limit: The system-wide max commit charge, it is the sum of the capacity of the paging files and physical RAM.
Virtual Memory: Amount of virtual address space being used by a process. Since virtual addresses can be reserved without actually taking up any memory, this value can be huge and often is not representative of how much memory is actually in use.

Note: Windows can reach an out-of-memory condition by exhausting physical memory or by reaching the commit limit. It is helpful to monitor both.

Metric mapping: Key memory types to monitoring sources

The following table shows which Datadog metrics to use for monitoring specific Windows memory types. For example, to monitor physical RAM usage, use system.mem.total, system.mem.usable, or system.processes.mem.rss. To track commit charge (private bytes), use system.mem.committed or system.processes.mem.vms.

Use the Live Processes metrics and native Windows Performance Counters columns to cross-reference data when troubleshooting or correlating across different monitoring tools.

Memory Type	Datadog System Metric	Live Processes Metric	Windows Performance Counter
Physical Memory	`system.mem.total` `system.mem.usable` `system.mem.pct_usable` `system.mem.used` `system.mem.shared` `system.processes.mem.rss`	RSS Memory RSS Memory %	`\Memory\Available Bytes` `\Process()\Working Set` `\Process()\Working Set - Private`
Commit Charge	`system.mem.pagefile.` `system.swap.` `system.mem.committed` `system.processes.mem.vms`	N/A	`\Memory\Committed Bytes` `\Process()\Private Bytes`
Commit Limit	`system.mem.pagefile.total` `system.swap.total`	N/A	`\Memory\Commit Limit`
Virtual Memory		Virtual Memory	`\Process()\Virtual Bytes`

Example: Windows Process Explorer

The following screenshots show how memory values displayed in Windows Process Explorer correspond to the metrics in the table above. The highlighted columns in Process Explorer show the Working Set (physical memory), Private Bytes (commit charge), and Virtual Size metrics that map to Datadog’s system metrics and Live Processes view.

The Windows Process Explorer with the agent.exe properties expanded — The Private Bytes value is mapped to system.processes.mem.vms, and the Working Set value is mapped to system.processes.mem.rss

The Memory tab of the System Information panel. Under Commit Charge, the Current value is mapped to system.mem.pagefile.used and system.swap.used, and the Limit value is mapped to system.swap.total and system.mem.pagefile. Under Physical Memory, the Total value is mapped to system.mem.total, the Available value is mapped to system.mem.available, and the Cache WS value is mapped to system.mem.cached

Understanding pagefile metric names

In Windows, pagefile and swap memory are considered the same thing, so the system.swap.* and system.mem.pagefile.* metrics report the same value.

It’s important to understand what the system.mem.pagefile.* metrics actually measure. The Datadog Agent collects these metrics from the Windows MEMORYSTATUS struct, which defines them as:

dwTotalPageFile: The current size of the committed memory limit, in bytes. This is physical memory plus the size of the page file, minus a small overhead.
dwAvailPageFile: The maximum amount of memory the current process can commit, in bytes. This value should be smaller than the system-wide available commit. To calculate this value, call GetPerformanceInfo and subtract the value of CommitTotal from CommitLimit.

Based on these definitions, the system.mem.pagefile.* metrics measure committed memory (commit charge and commit limit) rather than the pagefile size itself. Datadog preserves the Windows API naming convention for consistency.

What each metric measures:

system.mem.pagefile.total = Commit Limit (the maximum commit charge, not the pagefile size)
system.mem.pagefile.used = Current Commit Charge (memory committed by all processes, not pagefile usage)
system.mem.pagefile.free = Available Commit (remaining commit capacity, not free pagefile space)

Paging file metrics by Agent version

Datadog recommends upgrading to Agent version 7.76 or later to access clearer, more accurately named paging file metrics. Unlike the system.mem.pagefile.* metrics (which actually measure commit charge), these metrics directly monitor your pagefile.sys usage.

Agent versions 7.76 and later have the following metrics available for monitoring paging file (pagefile.sys) usage:

Metric	Description
`system.paging.total`	The total amount of allocated pagefile in bytes.
`system.paging.used`	The amount of pagefile that is used in bytes
`system.paging.pct_free`	The percentage of pagefile that is not used.
`system.paging.free`	The amount of pagefile that is not used in bytes.

If you are using an Agent version earlier than 7.76, the total size of all paging files (pagefile.sys) can be calculated with the following formula (open the Metric Explorer to try it out):

system.mem.pagefile.total - system.mem.total

The following performance counters can also be collected through the Windows Performance Counters integration:

\Paging File()% Usage
\Paging File()% Usage Peak