---
title: Windows Memory Metrics in Datadog
description: >-
  Understand Windows memory metrics and how they map to Datadog system metrics,
  Live Processes, and Windows Performance Counters.
breadcrumbs: Docs > Metrics > Metrics Guides > Windows Memory Metrics in Datadog
---

# Windows Memory Metrics in Datadog

## Overview{% #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](https://learn.microsoft.com/windows/win32/memory/memory-performance-information) documentation.

## Key terms{% #key-terms %}

{% dl %}

{% dt %}
Physical Memory
{% /dt %}

{% dd %}
Actual physical RAM that is in use. Sometimes also called the "working set" or RSS.
{% /dd %}

{% dt %}
Commit charge
{% /dt %}

{% dd %}
Total of all memory that must be backed by RAM or the paging files. Sometimes also called "private bytes".
{% /dd %}

{% dt %}
Commit limit
{% /dt %}

{% dd %}
The system-wide max commit charge, it is the sum of the capacity of the paging files and physical RAM.
{% /dd %}

{% dt %}
Virtual Memory
{% /dt %}

{% dd %}
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.
{% /dd %}

{% /dl %}

**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{% #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{% #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.

{% image
   source="https://datadog-docs.imgix.net/images/metrics/guide/windows_memory_metrics_in_datadog/windows_process_explorer.028aad364e892f9f6264c7267260397d.png?auto=format"
   alt="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
{% image
   source="https://datadog-docs.imgix.net/images/metrics/guide/windows_memory_metrics_in_datadog/windows_system_information.3c32b9da029686232a7ca37633f4ec28.png?auto=format"
   alt="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{% #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](https://learn.microsoft.com/windows/win32/api/winbase/ns-winbase-memorystatus), 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](https://learn.microsoft.com/windows/win32/api/psapi/nf-psapi-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{% #paging-file-metrics-by-agent-version %}

{% tab title="Agent 7.76 and later (recommended)" %}
**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. |

{% /tab %}

{% tab title="Agent 7.75 and earlier" %}
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](https://app.datadoghq.com/metric/explorer?graph_layout=stacked&split_mode=single&state=H4sIAAAAAAAACl2RXYrDMAyE76LHxZSk7bbUV1mKMbGcCvyTWk4hDbn7oqTtwr5Jw-fRSJ7hgYUpJ9Cwb_ZH07amaUFBX-xwY9A_Mzj0lKiu0AyVakDQAGorDdNT-vb0UWygXgwD-iriNAhQKSJjIWRQUPA-ItdtQEEecmI0Ppdo63_2Pm6VoMlG8RJpkpjOVms4j6UTOWIt1L3fTKDBPnrNE1eMu24YdyNjmb8WWK4KZNgY7Ob7av6sl-tyXQTjIVA1jiImuZPgH7XLyVO_GgSKVEG3jQLOpcqlcnFYQIND7mD1krV8WVeYgasVrj2fm_3hdDgf28O3AkzurV0uL62gL8g3E7OTLTmQo9SDgsGOjA60t4FxUeApVCyviJ_I5kFP8_6EPATiCssvmYyBFvkBAAA&paused=false#N4Ig7glgJg5gpgFxALlAGwIYE8D2BXJVEADxQEYAaELcqyKBAC1pEbghkcLIF8qo4AMwgA7CAgg4RKUAiwAHOChASAtnADOcAE4RNIKtrgBHPJoQaUAbVBGN8qVoD6gnNtUZCKiOq279VKY6epbINiAiGOrKQdpYZAYgUJ4YThr42gDGSsgg6gi6mZaBZnHKGABuMMgaWBoIcKoAdOrN8hjwwmhwTQg4CBhowABUPCB8oJHRubFYAEyJyQNpGdnK+YXFILPlVTV1Dc2tvf2DI2M8ALpUru54mKHht6r3GDGl8QAEALSfswtXKj1LDdGQgdrdBANZRQHAwJyZB4aCCZRJoURwJxyRTKdLoqBojFOehMZQiNweNDjfgQeyYLBYhQ5EDokRKK48PggOniADCUmEMBQInuaB4QA) 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`

{% /tab %}

## Further reading{% #further-reading %}

- [Metrics Summary](https://docs.datadoghq.com/metrics/summary/)
- [Metrics Explorer](https://docs.datadoghq.com/metrics/explorer/)
- [Live Processes](https://docs.datadoghq.com/infrastructure/process/)
- [Windows Performance Counters Integration](https://docs.datadoghq.com/integrations/windows_performance_counters/)
- [Basic Agent Usage for Windows](https://docs.datadoghq.com/agent/basic_agent_usage/windows/)