# Memory compression and the page file: what Windows actually does

> 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 on**

- Build: 26300.9457 / 26100.33650
- Edition: Pro (26H2) / Server
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

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

1. **Trims caches** — standby (cached) pages are given up first. This is free.
2. **Compresses** pages that are still needed — memory compression keeps them in RAM, compressed.
3. **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

```powershell
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?

```powershell
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.

```powershell
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.

> **Caution: Do not “clean” standby memory**
>
> Tools that "free RAM" by purging standby lists throw away cached file data that Windows deliberately kept. The next launch is slower, and nothing is gained. Windows already trims it when another process needs it.

## Deciding "do I need more RAM?"

Use a real workload, not idle numbers:

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

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

## Related

- [RAM sizing](https://winbook.fyi/en/hardware/ram/)
- [Channels and shared graphics memory](https://winbook.fyi/en/hardware/ram/channels-uma/)
- [Memory diagnostics](https://winbook.fyi/en/hardware/ram/diagnostics/)

## 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.

## Sources

- [Microsoft Learn — Memory management](https://learn.microsoft.com/en-us/windows/win32/memory/memory-management)
- [Microsoft Learn — Get-MMAgent](https://learn.microsoft.com/en-us/powershell/module/mmagent/get-mmagent)
- [Microsoft Learn — Win32_PageFileSetting](https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-pagefilesetting)
- [Microsoft Learn — Get-Counter](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-counter)

---

Source: https://winbook.fyi/en/hardware/ram/compression-pagefile/