Solving the WSL 2 Memory Leak: Managing Vmmem with .wslconfig

The Vmmem Memory Sink

Developers using Windows Subsystem for Linux (WSL 2) often encounter a frustrating problem: the Vmmem process consumes nearly all available system RAM, even when the Linux distribution is idling. This happens because the lightweight utility VM used by WSL 2 is designed to request memory from the Windows host as needed, but it is often reluctant to release it back to the host immediately.

The takeaway is that while WSL 2 provides a full Linux kernel for better system call compatibility, it does not automatically manage memory boundaries. To prevent your Windows host from swapping or crashing, you must manually define resource constraints using a global configuration file.

How WSL 2 Handles Resources

Unlike WSL 1, which acted as a translation layer, WSL 2 runs a real Linux kernel inside a Hyper‑V based virtual machine. This architecture allows for native performance and full compatibility with tools like Docker. However, this means the Linux kernel manages its own memory page cache.

When you perform memory‑intensive tasks—such as compiling a large C++ project or running a data science notebook—the Linux kernel caches files in RAM to speed up future access. To Windows, this looks like the Vmmem process is hoarding memory, even if the Linux OS reports that the memory is only being used for “cache” and not “active” processes.

Configuring Resource Limits with .wslconfig

To stop Vmmem from consuming your entire system, you can create a .wslconfig file. This is a global settings file that applies to all installed Linux distributions on your machine.

Implementation Steps

1. Open Windows Explorer and navigate to your user profile folder: %USERPROFILE% (usually C:\Users\YourName).
2. Create a new text file named .wslconfig. Ensure there is no .txt extension at the end.
3. Add the following configuration to limit memory and CPU usage:

[wsl2]
# Limit VM memory to 4GB
memory=4GB

# Limit VM processors to 2 cores
processors=2

# Enable automatic memory reclamation (Windows 11 22H2+)
autoMemoryReclaim=gradual

Applying the Changes

Changes to .wslconfig are not applied in real‑time. You must shut down the WSL subsystem completely. Run this command in PowerShell (Administrator not required):

wsl --shutdown

The next time you launch your Linux terminal, the constraints will be active.

The Performance Trade‑off: File System Latency

While limiting memory stabilizes the host, you should be aware of a separate architectural bottleneck: the 9P protocol. WSL 2 uses the 9P protocol to allow Linux to access files on your Windows drive (e.g., \\wsl$). This is significantly slower than accessing files stored within the native Linux ext4 filesystem.

Scenario	Storage Location	Performance	Recommendation
Project Source Code	/home/user/project	High (Native)	Store all active code here.
Shared Assets	/mnt/c/Users/Documents	Low (9P Protocol)	Use for static assets only.

If you notice slow build times despite having enough RAM, check if your project files are sitting on the Windows partition instead of the Linux root filesystem.

Verification and Diagnostics

To verify that your distribution is running on version 2 and respecting the kernel limits, use these checks:

• Check Version: Run wsl --list --verbose in PowerShell. The version column must show 2.
• Confirm Kernel: Inside the Linux terminal, run uname -a. You should see a kernel version identifying it as a Microsoft‑built kernel.
• Monitor Memory: Open Windows Task Manager and observe the Vmmem process after running a memory‑heavy command in Linux. It should now cap at the limit defined in your .wslconfig.