Fixing High vmmem Memory Usage in WSL2

The vmmem (or Vmmemwsl) process representing WSL2’s entire virtual machine growing to consume several gigabytes of RAM is expected behavior stemming from how WSL2’s dynamic memory allocation and Linux page caching work — but that doesn’t mean you’re stuck with an unbounded number.

Step 1: check what’s actually running inside WSL first

# from inside your WSL distro:
free -h
ps aux --sort=-%mem | head -10

Before assuming this is purely a caching artifact, confirm whether a specific running process inside WSL is genuinely consuming the memory you’re seeing reflected in vmmem — a forgotten background process (a database server, a leftover build process) is a common, easily-fixed cause.

Step 2: distinguish genuine usage from page cache

free -h
# check the "buff/cache" column specifically

Linux’s page cache holds recently-accessed file data in memory speculatively, for performance — this shows up as memory usage from Windows’s perspective but is reclaimable on demand, not memory actually pinned by a running process.

Step 3: manually drop caches to test this distinction

sync
echo 1 | sudo tee /proc/sys/vm/drop_caches

If vmmem’s reported usage drops significantly after this, the majority of what you were seeing was reclaimable page cache, not a genuine leak or runaway process.

Step 4: set a hard memory ceiling via .wslconfig

%UserProfile%\.wslconfig

[wsl2]
memory=4GB

This caps how much RAM the WSL2 VM can ever claim, regardless of Linux-side demand — after editing this file, run wsl --shutdown and restart your distro for the change to take effect.

Step 5: choose a ceiling based on your actual usage, not an arbitrary guess

Setting this too low can cause genuine out-of-memory pressure for workloads that legitimately need more (large builds, containers, memory-intensive applications) — check your actual peak usage via free -h under real working conditions before picking a specific ceiling.

Step 6: consider also limiting processor count if CPU, not memory, is the issue

[wsl2]
processors=4

If Task Manager shows high CPU usage attributed to vmmem rather than memory specifically, capping the processor count WSL2’s VM can use addresses that separately from the memory ceiling.

Step 7: fully restart WSL2 to reclaim everything at once

wsl --shutdown

This completely tears down the WSL2 VM, releasing all memory it was holding — the most thorough reset available, at the cost of ending every running WSL session and process, useful when you need memory back immediately rather than waiting for gradual reclaim.

Step 8: check for a specific known-leaking application rather than blaming WSL2 itself

If memory usage climbs continuously and never stabilizes even under a fixed workload, check whether a specific application inside WSL has a genuine memory leak — that’s an application-level bug, not a WSL2 platform issue, and setting a .wslconfig ceiling only masks a leak rather than fixing its actual cause.

Why setting a deliberate ceiling is the right long-term fix

Rather than repeatedly running wsl --shutdown to reclaim memory reactively, setting an appropriate .wslconfig memory limit once addresses the underlying concern proactively — bounding how large vmmem can ever grow, while still leaving enough headroom for your actual real-world WSL workloads to run without artificial memory pressure.

Checking whether you’re on a WSL version with improved reclaim behavior first

Before setting a restrictive ceiling to compensate for what you assume is WSL2’s memory behavior, confirm you’re on a reasonably current WSL version — later releases included genuine improvements to how proactively the VM releases memory back to Windows once Linux no longer needs it, narrowing the gap this fix addresses. Running wsl --update and re-observing actual behavior before committing to a specific ceiling avoids permanently working around a version-specific issue that a simple update might have already resolved.

Distinguishing container workloads as a specific, common driver

If Docker Desktop or another container runtime is running inside or alongside your WSL2 distributions, container image layers, volumes, and build cache are frequently the actual largest contributor to vmmem growth, distinct from your own project files. Checking docker system df for a breakdown of image, container, and volume disk usage identifies whether container-related storage — not a leak in your own application code — is the real driver, before assuming a .wslconfig ceiling alone addresses the underlying cause rather than just capping its visible symptom.

Related:

Sources: