Why Vmmem eats your RAM and what .wslconfig controls
WSL2 keeps freed Linux memory as a page cache instead of returning it to Windows, which is why Vmmem stays huge after a big build even though every program inside the distro is closed. That is normal kernel behavior, not a leak — but when the distros share the machine with a browser, an IDE and other VMs, the ceiling belongs in writing. The default 50% made sense when machines were empty; on a 16 GB box shared by five hungry apps it is simply too much.
The steering wheel is %UserProfile%\.wslconfig, read once when the VM starts — so every edit needs a wsl --shutdown to take effect. The limits apply to all distributions at once, and a per-distro cap is not possible through this file. It only affects WSL2: the first generation runs Linux calls inside Windows itself, with no VM and no Vmmem to limit.
- memory=6GB — the RAM ceiling for the entire VM, all distros together
- processors=4 — how many logical CPU cores WSL2 is allowed to see
- swap=4GB — size of the Linux swap file WSL2 may fall back to (default: 25% of RAM, capped at 8 GB)
- autoMemoryReclaim=gradual — experimental option that returns freed Linux memory to Windows (WSL 1.3.10+)
- sparseVhd=true — experimental option that lets the ext4.vhdx disk shrink when files are deleted
Setting the limits step by step
Open Notepad, paste the section header [wsl2] and under it the lines memory=6GB, processors=4 and swap=4GB, then save the file as %UserProfile%\.wslconfig. In the save dialog set Save as type to All files (*.*) and the encoding to UTF-8, or Windows silently creates a .wslconfig.txt that WSL never reads. A value without a unit, like memory=6, is interpreted as bytes — so the GB suffix is not decoration, it is required.
Open PowerShell or Windows Terminal and run wsl --shutdown, wait about ten seconds, then start your distro again. Inside Linux, free -h now shows the capped amount instead of your full physical RAM, and nproc prints the number of cores you allowed. If wsl --version reports 1.3.10 or newer, you can add an [experimental] section with autoMemoryReclaim=gradual and sparseVhd=true below the [wsl2] block and repeat the shutdown; on older WSL, run wsl --update from an elevated prompt first.
When to revisit the numbers
Watch Vmmem in Task Manager for a week of normal work: for browsing, editing and light containers 4–6 GB is plenty, while heavy Docker builds or large JavaScript toolchains may honestly need 8 GB or more. Move memory= in 2 GB steps rather than in one big jump, and on machines with 16 GB or less leave at least half of the physical RAM to Windows itself. If the disk hosting your distros keeps growing, sparseVhd=true stops ext4.vhdx from expanding monotonically. Recheck after every Windows feature update — they occasionally replace the WSL package and change its behavior.
Questions and Answers
How much memory should I give WSL2?
On a 16 GB machine, 6 GB covers everyday development with room to spare; at 8 GB total RAM stay at 4 GB so Windows does not start swapping. Raise the cap in small steps, and only when builds actually fail with out-of-memory errors.
Why is Vmmem still huge after I close everything inside Linux?
The kernel keeps freed memory as page cache and does not proactively hand it back to Windows. Run wsl --shutdown when you are done for the day, or enable autoMemoryReclaim=gradual on WSL 1.3.10+ so unused memory flows back automatically.
Does .wslconfig work with WSL1 distributions too?
No. WSL1 translates Linux calls inside Windows itself — there is no VM, no Vmmem and nothing to cap. If you want limits, convert the distro first with wsl --set-version <name> 2.
Know what is included before you buy.
The one-time 30-minute trial covers core tools. PRO-labelled features stay locked until a paid license is activated.
Read next
Write to us: [email protected]