Memory compression and the page file: what Windows actually does

Verified 2026-10-292 min read

How standby memory, memory compression and the page file interact, how to read the counters, and why 'free RAM' is the wrong number to watch.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64

Build: 26300.9457 / 26100.33650
Edition: Pro (26H2) / Server
Architecture: x64
Support: Documentation (E1)
Evidence: E1Official documentation
Verified: 2026-10-29
Page type: Concept

The short answer

When physical memory gets tight, Windows does three things in this order:

Trims caches — standby (cached) pages are given up first. This is free.
Compresses pages that are still needed — memory compression keeps them in RAM, compressed.
Writes pages that cannot be compressed usefully to the page file.

“Free RAM” only counts memory doing nothing. The number that matters is available memory, which includes standby and free.

Read the right counters

Get-Counter '\Memory\Available MBytes','\Memory\Committed Bytes','\Memory\Commit Limit','\Memory\Pages/sec' -MaxSamples 3
Get-Counter '\Memory\Standby Cache Normal Priority Bytes' -MaxSamples 2
Get-CimInstance Win32_OperatingSystem |
  Select-Object @{n='TotalGB';e={[math]::Round($_.TotalVisibleMemorySize/1MB,1)}},
                @{n='FreeGB';e={[math]::Round($_.FreePhysicalMemory/1MB,1)}},
                @{n='CommitGB';e={[math]::Round($_.TotalVirtualMemorySize/1MB,1)}}

Counter	Meaning	Warning sign
`Available MBytes`	free + standby	persisting near zero while apps are open
`Committed Bytes` vs `Commit Limit`	demand vs what the system can back	sustained above ~90%
`Pages/sec`	hard faults moving pages to/from disk	sustained high values with an SSD already busy
`Standby Cache … Bytes`	cached file data	collapsing to near zero under load

A system with 2GB “free” and 6GB standby is healthy. A system with 500MB available and constant paging is not.

Is memory compression on?

Get-MMAgent | Select-Object MemoryCompression,PageCombining

MemoryCompression : True means the compression store is active. It is on by default on current Windows client builds. Page combining (PageCombining) deduplicates identical pages — useful for VMs and many similar processes.

On Windows Server, memory compression is intentionally conservative: servers usually have enough RAM and predictable workloads, and compression costs CPU. Do not turn it on “because desktops have it”.

Page file sizing, without folklore

The old rule (“1.5× RAM”) predates SSDs and 64GB desktops. What actually matters:

Do you need a page file at all? Yes — some Windows features and crash dumps require one. “Disable page file for performance” is a myth that breaks things.
System managed is the sane default. It grows when needed and is small otherwise.
Fixed size is for predictable servers: set a floor large enough for the working set plus a crash dump if you need dumps.
Separate disk only matters if that disk is actually faster or less contended.

Get-CimInstance Win32_PageFileSetting | Select-Object Name,InitialSize,MaximumSize
Get-CimInstance Win32_PageFileUsage | Select-Object Name,AllocatedBaseSize,CurrentUsage,PeakUsage

PeakUsage close to AllocatedBaseSize means the file is being sized by demand — either give it a floor or add RAM.

Deciding “do I need more RAM?”

Use a real workload, not idle numbers:

Open your normal apps for a day.
Watch Available MBytes and Committed Bytes / Commit Limit.
If committed memory stays above ~90% of the limit and Pages/sec is sustained, you are short.
If committed is moderate but one process’s working set keeps growing, you have a leak — more RAM only delays it.

Get-Process | Sort-Object WorkingSet64 -Descending |
  Select-Object -First 10 Name,@{n='WS_MB';e={[math]::Round($_.WorkingSet64/1MB)}}

Lab boundary

E1. The counters and agent behaviour are Microsoft-documented. This page does not publish compression ratios from the lab, because a 2-vCPU VM’s ratio would not transfer to a real desktop.