VmmemWSL High Memory: Find the Work Before Reclaiming RAM

VmmemWSL in Task Manager represents resources used by the WSL virtual-machine environment. Its memory can include active Linux workloads and cache. If Docker, an AI model server or development tools run there, ending a Windows editor does not necessarily stop that work.

First determine whether memory belongs to a running task or remains cached after the task ends. Deleting a WSL virtual disk is not a memory fix and can destroy the Linux environment and its data.

Find the work inside WSL

From PowerShell, inspect the installed environment:

wsl --version
wsl --list --verbose
wsl --list --running

Inside the relevant Linux distribution, use these read-only views:

free -h
ps -eo pid,comm,rss --sort=-rss

The Linux readings do not have exactly the same scope as Task Manager's VM total. Use them to locate processes and distinguish available memory from file cache, not to force every number to add up. For Docker-owned work, inspect Docker Desktop's running containers and stop the intended job through its normal control.

An AI server may keep a model loaded after answering. Stop that workload deliberately if it is no longer needed. Do not kill an arbitrary process simply because its name is unfamiliar.

Read a Linux memory sample without calling every cache a leak

In the free -h output, pay attention to available as well as used and buff/cache. Linux uses otherwise idle memory for file data, and some of that memory can be reclaimed when applications need it. A small free value alone is therefore not enough to establish that Linux is out of memory.

The process listing reports RSS in KiB, while free -h uses human-readable units. Shared pages and VM overhead also mean that summing process rows will not necessarily equal Task Manager's VmmemWSL number. Use the largest rows to identify the owner, then inspect the named workload, rather than forcing the totals to match.

If Docker is involved, these read-only commands identify running containers and take one resource sample, following the Docker stats reference:

docker ps
docker stats --no-stream

Run them in the environment connected to the Docker backend being investigated. A different Docker context can describe a remote machine, so confirm the target before acting. A container's displayed memory figure and the whole WSL VM total have different scopes.

Compare three states: before the AI job starts, while it is running and after the application has normally unloaded its model or stopped the job. If the large process remains alive, cache reclamation is not a substitute for deciding whether that process should keep running. If the process shrinks but cache remains, reclamation behavior becomes a more relevant question.

Check the current reclamation setting

Microsoft's WSL configuration reference places global WSL 2 settings in %USERPROFILE%\.wslconfig. It is different from /etc/wsl.conf inside a distribution.

The current reference lists autoMemoryReclaim under [experimental], with dropCache as its default and gradual as another supported mode. Older advice to enable a universally disabled default can therefore be stale. Check the installed WSL version and your existing configuration before adding anything.

If you deliberately want gradual cache reclamation on a version supporting the setting, merge this entry into the existing file:

[experimental]
autoMemoryReclaim=gradual

Do not overwrite unrelated settings or create duplicate sections. This changes how cached memory is reclaimed; it does not make an active model or database require less memory. Compare the same workload before deciding whether to retain the change.

Edit the existing configuration and keep a way back

Open %USERPROFILE% in File Explorer and enable filename extensions before creating or editing .wslconfig. A file accidentally saved as .wslconfig.txt is not the intended configuration. Copy an existing configuration to a backup first and preserve sections unrelated to memory.

Under one existing [experimental] section, change only the reclamation entry being tested. A new file is needed only if no configuration exists and an intentional setting change is warranted. Do not add both dropCache and gradual lines or duplicate the section after copying examples from different articles.

The default documented by Microsoft already reclaims cache. Changing it to gradual is a policy experiment, not an upgrade that always saves more memory. It may leave cache resident for longer than immediate reclamation. If there is no demonstrated problem with the current behavior, leave the default in place and investigate the active workload instead.

After applying a change through a safe WSL restart, repeat the same job and observe Windows responsiveness, Linux available memory and whether the job completes. If the change is unhelpful, restore the previous entry from the backup, then apply that restoration with the same save-and-restart precautions. Do not erase the entire configuration to remove one experimental line.

Restart WSL only after saving its work

Configuration changes apply when the WSL environment restarts. Microsoft's basic commands document the global shutdown command:

wsl --shutdown

Before using it, save files, stop training or inference jobs, and shut down affected containers or databases normally. The command stops all running distributions and the WSL 2 VM, including work behind Docker Desktop. It is not a selective memory-trimming button.

If VmmemWSL memory disappears after shutdown, that confirms the stopped environment owned it. It does not distinguish a leak from an active task or useful cache. Restart the needed services and compare after the same work completes.

Use a memory cap as a budget, not a repair

The .wslconfig memory setting limits WSL 2's available memory. A cap that is too low can cause Linux applications to fail or swap heavily. It does not remove a program's requirement. Choose it only after measuring the workload and the RAM Windows also needs, then check the application completes successfully.

Docker Desktop's WSL guidance discusses memory reclamation for its WSL backend. Keep the configuration at that backend rather than applying unrelated Hyper-V instructions.

Confirm that a memory cap has actually taken effect

If a cap is needed, place memory under [wsl2] in the existing configuration. For example, memory=8GB means an 8 GB limit, not 8 GB reserved for each distribution. That is a syntax example, not a recommended budget for every PC. Several WSL 2 distributions share the global VM budget, so include their concurrent work when choosing it.

After saving work and restarting WSL, inspect the total reported by free -h inside a distribution and compare it with the intended limit, allowing for system overhead. Then run the actual model or build. A smaller Task Manager figure is not success if the Linux job is now killed or spends its time swapping.

If the limit seems ignored, check the Windows account owning the file, its extension, whether the target distribution is WSL 2 and whether the old VM fully stopped. These checks are more informative than repeatedly lowering the number. Do not turn off swap as a second simultaneous experiment, since that changes how the workload behaves when it reaches its budget.

For Docker workloads, keep Docker's normal shutdown and data persistence behavior intact. Closing a terminal does not necessarily stop its container, while a global WSL shutdown can interrupt several unrelated services. Save database and training work through their own application controls before applying a VM-wide change.

Keep RAM and virtual-disk space separate

The Windows memory guide covers the host-side readings. For disk capacity, use the separate Docker and WSL storage guide. Never use wsl --unregister as a cleanup shortcut: it removes a distribution and its data rather than solving a high-memory reading.