WSL2 Memory/CPU Limits: Stop It from Eating Your RAM

How WSL2 actually uses memory and CPU

WSL2 is not “Linux running in a compatibility layer.” That was more like WSL1. WSL2 runs a real Linux kernel inside a lightweight virtual machine managed by Hyper-V. This is why WSL2 has better syscall compatibility and why it can also eat your lunch in the form of RAM pressure.

The mental model that won’t betray you

• Windows owns the hardware. WSL2 is a guest VM. The guest can request memory and CPU; the host schedules and backs it.
• WSL2 memory is “elastic” until it isn’t. The VM can grow as Linux caches file data, allocates memory for builds, or runs containers.
• Linux will use “free” RAM for cache. This is normal. The failure mode is when that cache doesn’t get returned to Windows quickly enough, or when the VM hits a limit and starts swapping.
• vmmem is the bill. Task Manager doesn’t show “WSL2 process memory” the way you want; it shows the VM container process. That includes Linux kernel, page cache, and everything you started inside WSL2.

CPU is simpler: without limits, WSL2 can use as many cores as Windows will schedule. If you’ve ever watched a Rust build or a parallel make -j annihilate interactivity, you’ve seen the default policy: “Congratulations, you bought cores; we will use all of them.”

One quote to keep you honest, a paraphrased idea from Gene Kim (reliability/ops author): paraphrased idea: fast flow and stable systems come from reducing work-in-progress and limiting blast radius. Resource limits are literally blast-radius control.

Short joke #1: WSL2 doesn’t “leak memory.” It just adopts it permanently and names it after your build directory.

Interesting facts and historical context (the parts you don’t hear at standup)

1. WSL1 vs WSL2 was a philosophical pivot. WSL1 translated Linux syscalls to Windows. WSL2 ships a real Linux kernel, which fixed compatibility but reintroduced VM-style resource behavior.
2. The vmmem process is a Hyper-V container. It’s the host-side representation of the WSL2 VM. That’s why it looks “mysterious” in Task Manager and why killing random Linux processes won’t necessarily reduce it quickly.
3. Linux page cache is not “wasted RAM.” It’s performance. When it becomes a problem, the problem is reclamation across the VM boundary, not Linux being “greedy.”
4. Memory ballooning is a known VM technique. Hypervisors can reclaim guest memory with balloon drivers. WSL2’s behavior has improved over time, but it’s not magic and it’s not instantaneous.
5. WSL2 has had a history of “memory not returning.” Early builds were notorious for it. Newer Windows 11 + WSL updates improved reclamation, especially with features like page reporting.
6. Docker’s WSL2 backend changed the game. Instead of a heavy LinuxKit VM, Docker Desktop can run inside WSL2, which makes WSL2 resource policy suddenly everyone’s problem, not just “Linux devs.”
7. Swap inside WSL2 is not Windows pagefile. WSL2 can have its own swap file. You can tune it, and you should, because “swap by surprise” is how laptops start sounding like they’re processing gravel.
8. Systemd support in WSL2 was a big shift. More background services can run, which is great for realism and also great for silently consuming RAM and CPU if you treat WSL like a disposable shell.
9. CPU limits are blunt but effective. The VM is not a cgroup sandbox by default. If you want “Linux dev workloads don’t steal Windows interactivity,” VM-level CPU caps are a surprisingly clean hammer.

Fast diagnosis playbook

When the machine feels slow, do not start by editing config files. First figure out what kind of slow you’re dealing with. There are three common bottlenecks: host memory pressure, guest memory pressure, and CPU contention. Disk is the sneakier fourth.

First: is Windows choking on RAM or CPU?

• Check Task Manager: Memory graph, CPU graph, and which processes are top offenders (vmmem vs everything else).
• Decision: If Windows is paging heavily or memory is >90% used, treat it as a host memory emergency. If CPU is pegged, treat it as a scheduling/contention issue.

Second: is WSL2 the culprit or just nearby?

• Check WSL distros: Find what’s running and whether a container stack is involved (Docker Desktop, Kubernetes, build jobs).
• Decision: If vmmem is huge and growing, confirm what inside Linux is using memory (RSS) vs cache. If CPU is high, confirm if it’s compilation, containers, or background services.

Third: is memory “stuck” or legitimately used?

• Inside WSL: Look at free -h, ps, and /proc/meminfo to separate anonymous memory (apps) from page cache.
• Decision: If it’s mostly cache and Windows is suffering, you need limits or forced reclaim/shutdown strategy. If it’s real process memory, fix the workload (or accept it and cap it).

Fourth: disk thrash check (because swap and I/O lie)

• Inside WSL: If swap is active and I/O wait is high, your “memory problem” is now a disk problem.
• Decision: Reduce memory usage, increase RAM allocation (counterintuitive but sometimes right), or tune swap to avoid catastrophic thrash.

Set hard limits with .wslconfig (and what each knob really does)

If you run WSL2 like a production service—and you should, because it behaves like one—then you set budgets. Budgets protect the host. They also force you to notice when workloads are growing beyond what your laptop is meant to do.

Where the config lives and how it applies

.wslconfig is read by WSL on the Windows side. It lives in your Windows user profile directory (typically C:\Users\<you>\.wslconfig). It applies globally to WSL2 VMs, not per distro.

After editing it, you usually need to shut down WSL so it restarts with the new settings. “Restarting the terminal” is not a restart. WSL is sneakier than that.

Opinionated baseline settings

On a typical 16 GB dev laptop, I like giving WSL2 enough headroom to be fast without letting it become the operating system. A reasonable starting point:

cr0x@server:~$ cat /mnt/c/Users/$USER/.wslconfig
[wsl2]
memory=8GB
processors=4
swap=4GB
swapFile=C:\\Users\\%USERNAME%\\AppData\\Local\\Temp\\wsl-swap.vhdx
localhostForwarding=true

What each line means in practice:

• memory=8GB: hard cap on VM memory. If the guest wants more, it will reclaim cache, then swap, then suffer. This protects Windows.
• processors=4: maximum vCPU count. It doesn’t “pin” CPUs; it limits parallelism. This protects responsiveness during builds and container storms.
• swap=4GB: size of WSL2 swap. This is not a performance feature; it’s a failure buffer. Too small and you OOM. Too large and you can thrash silently.
• swapFile=...: where swap lives. Put it on fast storage. Don’t put it on networked profiles, encrypted folders with weird policies, or anywhere that triggers corporate DLP drama.
• localhostForwarding=true: keeps networking sane. Not a resource knob, but people break it and then misdiagnose “slowness” that is actually DNS or port forwarding.

Choosing limits that won’t sabotage you

There’s no universal “best” number. There is, however, a universal failure mode: setting limits so low that the guest swaps constantly, and then blaming WSL2 for being slow. That’s like putting a governor on a car at 20 mph and complaining the highway is stressful.

Use these rules of thumb:

• Memory: If the host has 16 GB, set WSL2 to 6–10 GB depending on how much you run on Windows. If you’re running heavy IDEs on Windows, go lower.
• CPU: Cap to half your cores for developer machines. If you have 12–16 cores, give WSL2 6–8. If you have 4 cores, give it 2 and accept reality.
• Swap: 2–8 GB is common. If you compile huge projects or run Kubernetes, err higher. If you care about interactive latency, err lower and fix memory usage instead.

Short joke #2: Swap is like caffeine: a little keeps you alive, too much makes you jittery and unpleasant to be around.

Reclaiming memory: why “it should free RAM” is not a plan

The most common complaint is: “I closed everything in Linux, but Windows still shows vmmem using 10 GB.” Sometimes that’s a bug. Often it’s just physics: the guest has used memory for cache, and the host doesn’t immediately claw it back.

What’s usually happening

• Linux cached file data. Builds, package installs, and container image pulls all populate page cache.
• The guest is idle but still holding pages. Those pages are “reclaimable” inside Linux, but the host doesn’t necessarily force reclamation until pressure exists.
• Windows sees the VM allocation, not Linux “free.” So you see a big number and assume it’s active usage.

What you can do about it

There are three layers of response, from least to most disruptive:

1. Do nothing until the host needs it. If Windows has plenty of free memory and you’re not paging, don’t optimize by vibes.
2. Apply sensible caps. This is the long-term fix: WSL2 can’t balloon beyond a budget.
3. Restart WSL when you’re done with heavy work. This is the pragmatic “free everything now” button. It’s not elegant. It’s effective.

Also: if you’re consistently hitting the cap, that isn’t WSL2 misbehaving. That’s your workload telling you it wants more RAM than your machine can comfortably provide. Either adjust limits upward, reduce parallelism, or stop pretending a laptop is a build farm.

Swap, storage, and the slow death of your SSD

Swap is not free. It is deferred pain. On developer machines, swap tends to show up during “peak chaos”: parallel compiles, a handful of containers, browser tabs breeding in the background, and some innocent person opening Teams.

Why swap is especially sneaky in WSL2

• You can have swap inside the guest (WSL2’s swap file) while Windows has its own pagefile. Under pressure, you can end up paging twice: Windows paging the VM backing store while Linux swaps inside it. It’s as fun as it sounds.
• I/O wait becomes your real bottleneck. CPU graphs might look “fine,” but everything stalls because you’re waiting on disk.
• Swap size interacts with limits. A tight memory cap plus a large swap can keep a workload limping instead of failing fast. That’s either “productive” or “extended suffering,” depending on your deadlines.

Storage placement matters

WSL2 uses a virtual disk (VHDX) for each distro. That disk typically sits under your Windows profile. If you have a slow system drive, everything in WSL2 inherits that pain—especially container layers, package caches, and build artifacts.

If you want WSL2 performance, keep high-churn workloads inside the Linux filesystem (ext4 in the VHDX) rather than working from /mnt/c. The Windows filesystem interop is good, but it’s not “native Linux filesystem” good.

Docker Desktop and Kubernetes on WSL2: who’s actually in charge?

Once Docker gets involved, many teams lose track of where resource control lives. They tune Docker limits, then wonder why vmmem still grows. Or they tune WSL2 limits and wonder why Kubernetes falls over.

Understand the hierarchy

• WSL2 VM limit caps the entire Linux VM. Docker inside it is downstream of that cap.
• Docker resource settings (if using Docker Desktop UI) may or may not apply the way you think depending on backend and version. When the backend is WSL2, WSL2 limits are the hard ceiling.
• Kubernetes adds background churn. Even “idle” clusters run control plane components, controllers, and watchers. That’s steady-state CPU wakeups and memory footprint.

My operational advice: decide whether your laptop is allowed to host a local cluster and enforce that decision with limits. If you do allow it, budget for it. Don’t let it be an accidental passenger.

Practical tasks: commands, outputs, and the decisions you make

These are the hands-on checks I actually use. Each task includes a command, representative output, and what you decide from it. Run Windows-side commands in PowerShell; run Linux-side commands inside WSL.

Task 1: Confirm WSL version and what’s running

cr0x@server:~$ wsl.exe --list --verbose
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2
  Debian          Stopped         2

Meaning: Ubuntu is running on WSL2. Debian is stopped. If you thought “nothing is running,” you were wrong.

Decision: If vmmem is high, focus on the running distro(s). Stop what you don’t need.

Task 2: Hard reset WSL to reclaim host memory

cr0x@server:~$ wsl.exe --shutdown

Meaning: All WSL distros and the WSL2 VM are terminated. Memory should drop shortly after.

Decision: Use this when Windows is under pressure now. Do not use it as a daily ritual to avoid setting limits.

Task 3: See host-side WSL memory footprint (quick and dirty)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Process vmmem | Select-Object Name,Id,@{n='WS(MB)';e={[math]::Round($_.WorkingSet64/1MB,0)}},CPU"
Name  Id   WS(MB) CPU
vmmem 9480 10324  812.55

Meaning: The VM is holding about 10 GB working set. CPU time indicates it has been active.

Decision: If Windows is paging and this is large, apply a memory cap and/or shut down WSL.

Task 4: Check memory inside WSL (separate cache from pressure)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.6Gi       2.1Gi       1.2Gi       128Mi       4.3Gi       5.1Gi
Swap:          4.0Gi       0.0Gi       4.0Gi

Meaning: Most memory is in buff/cache, but available is healthy. This is not an emergency inside Linux.

Decision: If Windows is fine, ignore it. If Windows is not fine, caps/reclaim matter more than chasing “used.”

Task 5: Identify top memory users (real RSS, not vibes)

cr0x@server:~$ ps aux --sort=-rss | head -n 8
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1321  3.2  6.1 912648 475832 ?       Ssl  09:12   2:44 dockerd
cr0x      4882  1.1  4.8 2879300 376544 ?      Sl   10:01   0:51 node
cr0x      5021 18.9  4.2 1845500 332100 ?      Rl   10:05   1:32 rustc
postgres  2110  0.7  2.0  891200 158300 ?      Ssl  09:20   0:33 postgres
root       823  0.2  1.1  368012  88224 ?      Ss   09:10   0:08 containerd

Meaning: This is real process memory (RSS). Here, Docker and builds are major consumers.

Decision: If you’re hitting caps, reduce parallelism, stop services, or move heavy workloads off-laptop.

Task 6: See if you are swapping inside WSL

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   4G  512M   -2

Meaning: Swap is in use. Not automatically bad, but it’s a performance warning label.

Decision: If interactive performance is poor, treat swap usage as a trigger to reduce workload or raise memory cap.

Task 7: Find I/O wait (is disk the real bottleneck?)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 524288 842000  68000 3380000  20   45  1200   800  560  940 18  7 62 13  0
 1  1 524288 812000  68000 3310000  10   25  2400  1900  620 1020 12  6 58 24  0
 0  1 524288 798000  68000 3290000   0   12  3100  2200  640 1090 10  5 52 33  0

Meaning: wa (I/O wait) is rising. Swap in/out is happening. You are now paying interest on memory debt.

Decision: Reduce memory pressure first. If it persists, consider faster storage placement, less swap, or fewer concurrent jobs.

Task 8: Check CPU contention and load inside WSL

cr0x@server:~$ uptime
 10:14:22 up  1:08,  0 users,  load average: 9.12, 7.44, 5.81

Meaning: Load average is high relative to allocated CPUs. If you capped CPUs at 4 and load is 9, you have a queue.

Decision: Either raise processors or reduce parallelism (make -j, build tools, container replicas).

Task 9: Confirm how many CPUs WSL thinks it has

cr0x@server:~$ nproc
4

Meaning: Your current WSL2 VM sees 4 CPUs. That matches a processors=4 cap.

Decision: If builds are painfully slow but Windows is idle, increase CPU cap. If Windows is suffering, keep it capped.

Task 10: Locate the real disk usage culprits in WSL

cr0x@server:~$ sudo du -xh /var/lib | sort -h | tail -n 8
1.1G	/var/lib/apt
2.4G	/var/lib/snapd
6.2G	/var/lib/docker
6.2G	/var/lib/docker/overlay2
7.9G	/var/lib

Meaning: Docker storage dominates. This correlates with memory pressure too (page cache, metadata churn).

Decision: Prune images/volumes, move builds, or accept that local container hoarding has costs.

Task 11: See memory limits currently applied from Windows (sanity check your config)

cr0x@server:~$ cat /proc/meminfo | head -n 5
MemTotal:        7961888 kB
MemFree:         1214320 kB
MemAvailable:    5389120 kB
Buffers:           68040 kB
Cached:          3129480 kB

Meaning: MemTotal is about 7.6–7.9 GB, which implies your WSL2 memory cap is in effect.

Decision: If you expected 16 GB and got 8 GB, your cap is too low for that workload (or it’s the right cap and the workload needs to change).

Task 12: Check for systemd services quietly eating resources

cr0x@server:~$ systemctl --no-pager --type=service --state=running | head -n 12
  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
  cron.service                  loaded active running Regular background program processing daemon
  dbus.service                  loaded active running D-Bus System Message Bus
  docker.service                loaded active running Docker Application Container Engine
  rsyslog.service               loaded active running System Logging Service
  ssh.service                   loaded active running OpenBSD Secure Shell server
  systemd-journald.service      loaded active running Journal Service

Meaning: Docker and SSH are running, plus baseline services. This is real background footprint.

Decision: Stop what you don’t need. If you only use Docker occasionally, don’t let it idle forever.

Task 13: Stop a heavy service and confirm the delta

cr0x@server:~$ sudo systemctl stop docker
cr0x@server:~$ ps aux --sort=-rss | head -n 5
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cr0x      4882  0.8  4.6 2879300 362112 ?      Sl   10:01   0:54 node
postgres  2110  0.7  2.0  891200 158100 ?      Ssl  09:20   0:33 postgres
root       823  0.1  0.9  342200  72140 ?      Ss   09:10   0:08 containerd

Meaning: Docker-related processes dropped. Memory should reduce over time; CPU wakeups will reduce immediately.

Decision: If this materially improves Windows responsiveness, you’ve found a major contributor. Set policy: don’t run Docker 24/7 unless you mean it.

Task 14: Confirm Windows sees limits after restart

cr0x@server:~$ wsl.exe --shutdown
cr0x@server:~$ wsl.exe -d Ubuntu-22.04 -- cat /proc/meminfo | head -n 1
MemTotal:        7961888 kB

Meaning: The VM restarted and is still capped at ~8 GB.

Decision: If it didn’t change, you edited the wrong file, used invalid syntax, or didn’t restart the VM.

Three corporate-world mini-stories (because production always has opinions)

Mini-story 1: The incident caused by a wrong assumption

One team rolled out WSL2 as the default developer environment. It was a reasonable move: consistent tooling, fewer “works on my machine” debates, and easier onboarding. They told everyone, “It’s lightweight.” The phrase did damage.

Within a week, laptop complaints piled up: VPN drops, Teams freezing mid-call, the whole Windows UI stuttering. IT initially blamed endpoint protection. Developers blamed Windows updates. The reality was simpler: people were running container-heavy stacks all day, and WSL2’s VM happily expanded to fill memory. The host started paging, and everything that relies on predictable latency began to wobble.

The wrong assumption wasn’t “WSL2 is bad.” It was “WSL2 is small by default.” In a VM world, “default” usually means “uncapped.” They fixed it by publishing a standard .wslconfig baseline (memory and CPU caps), plus an internal rule: if you need more, you request it and justify it.

The surprising part: build times barely changed. Interactive stability improved immediately. That’s what happens when you stop fighting over the last 2 GB of RAM like it’s a scarce mineral.

Mini-story 2: The optimization that backfired

Another org had a well-meaning performance crusade: “Make builds faster by giving WSL2 more cores.” They pushed a config that set processors equal to the machine’s full core count. Compiles flew. Everyone posted screenshots. Momentum happened.

Then came the backfire: developers also run Windows IDEs, browsers, and security agents. Giving WSL2 all CPUs didn’t “steal” them permanently, but it created persistent contention. Parallel builds, container health checks, and background indexing inside WSL2 produced constant runnable threads. Windows stayed responsive in the trivial sense (the mouse moved) but latency-sensitive work degraded: video calls, screen sharing, even typing lag under load.

They attempted a second “fix”: lowering WSL2’s memory cap while keeping CPU unlimited. That turned the system into a swap factory. Builds got slower than before. Worse, they got unpredictable—fast on Monday, miserable on Tuesday, depending on whatever else was running.

The actual solution was boring: cap CPU to a sane fraction, cap memory to protect the host, and tune build parallelism per project. Peak throughput dropped slightly. Median developer experience improved a lot. In corporate environments, median is what you ship.

Mini-story 3: The boring but correct practice that saved the day

A platform team maintained a “known good dev workstation profile.” It wasn’t glamorous. It was a small set of defaults: a .wslconfig file, a standard Docker configuration, and a checklist for heavy repos. People grumbled about central control, the way they always do until something breaks.

Then a large dependency update hit. Builds expanded in memory usage, container images grew, and local test clusters became heavier. The org that didn’t have standards started firefighting: “Why is everyone’s machine melting?” The org with the profile saw some slowdowns, sure, but they didn’t see mass instability.

Because their profile included a simple practice: before large builds or cluster work, developers ran a quick health check (memory available, swap usage, running services). And after, they shut down WSL if they were done. It wasn’t fancy automation; it was operational hygiene.

When the dependency bump increased memory needs, the platform team adjusted the baseline limits carefully and communicated the tradeoffs. Nobody loved it, but nobody lost a day to mystery lag. Boring saved the day again. That’s basically SRE in one sentence.

Common mistakes: symptom → root cause → fix

1) Symptom: Windows is slow, Task Manager shows vmmem using “too much” RAM

Root cause: WSL2 VM ballooned due to page cache or workload memory, and the host is now under memory pressure.

Fix: Set memory= in .wslconfig, then wsl.exe --shutdown. If you need the memory back immediately, shutdown first, then tune.

2) Symptom: WSL2 is slow even though you “gave it limits”

Root cause: Limits are too tight and Linux is swapping or constantly reclaiming cache.

Fix: Check swapon --show and vmstat. Increase memory or reduce workload parallelism. Don’t starve the guest and expect speed.

3) Symptom: CPU pegged, Windows UI stutters during builds

Root cause: WSL2 has too many vCPUs or build tools are oversubscribing threads.

Fix: Set processors= to a sane value. Also tune build concurrency (for example, lower -j or tool-specific worker counts).

4) Symptom: vmmem stays large after stopping Linux processes

Root cause: Page cache remains allocated; host reclamation is not immediate.

Fix: Accept it if the host has headroom. If not, use wsl.exe --shutdown and implement caps so it doesn’t grow beyond budget.

5) Symptom: Disk is busy, fans spin, everything pauses periodically

Root cause: Swap and heavy filesystem activity (often Docker overlays) causing I/O wait spikes.

Fix: Reduce memory pressure, prune Docker storage, avoid heavy builds on /mnt/c, and keep swap modest. If you need huge memory, upgrade RAM instead of “tuning harder.”

6) Symptom: Networking looks slow; people blame CPU or memory

Root cause: Often DNS misconfiguration, VPN interaction, or localhost forwarding issues—masked as “system slowness.”

Fix: Verify WSL is actually CPU/memory bound before tuning. Keep localhostForwarding=true unless you have a specific reason not to.

7) Symptom: After editing .wslconfig, nothing changes

Root cause: File is in wrong location, syntax is invalid, or WSL wasn’t restarted.

Fix: Ensure it’s in the Windows user profile path, validate keys, then wsl.exe --shutdown and start the distro again. Confirm with /proc/meminfo and nproc.

Checklists / step-by-step plan

Plan A: Stop WSL2 from eating your RAM (without breaking your workflow)

1. Measure first. Check vmmem working set and Windows memory pressure.
2. Inventory what’s running. wsl.exe --list --verbose, then inside WSL check top processes.
3. Decide your budget. Pick memory and CPU caps based on your host RAM/cores and what must remain responsive on Windows.
4. Apply .wslconfig. Set memory, processors, and swap intentionally.
5. Restart WSL. wsl.exe --shutdown and relaunch your distro.
6. Validate the limits. Use /proc/meminfo and nproc.
7. Watch swap. If swap grows during normal work, the limits are too low or the workload is too heavy.
8. Fix the workload. Stop background services you don’t need, prune container storage, reduce build parallelism.

Plan B: Your laptop is already on fire (triage mode)

1. Immediate relief: wsl.exe --shutdown.
2. Confirm Windows recovers: memory drops, disk stops thrashing, UI becomes responsive.
3. Apply caps before restarting heavy workflows: create or adjust .wslconfig.
4. Restart only what you need: start one distro; avoid auto-starting Docker/Kubernetes until you confirm stability.
5. Re-run the fast diagnosis playbook: verify whether the next bottleneck is CPU, memory, or disk.

Plan C: Make it sustainable for teams

1. Standardize a baseline. Publish a recommended .wslconfig for common laptop tiers (16 GB, 32 GB).
2. Define escalation paths. If someone needs 20 GB in WSL2, that’s a hardware request or a remote build strategy, not a secret local tweak.
3. Teach “cache is not evil.” Teach people to read available memory, swap usage, and I/O wait.
4. Build with budgets. CI should represent reality; don’t let local dev environments sprawl into mini-datacenters without guardrails.

FAQ

1) Why does WSL2 use so much RAM even when I’m “doing nothing”?

Because Linux caches aggressively and WSL2 is a VM. “Nothing” often includes Docker daemons, watchers, language servers, and cached filesystem data. Check free -h and look at available vs buff/cache.

2) Is it safe to cap WSL2 memory?

Yes. It’s often the correct move. The risk is setting it too low and forcing swap or OOM kills inside Linux. Cap it high enough for your real workload, not your optimistic one.

3) Why doesn’t closing my Linux apps immediately reduce vmmem in Task Manager?

Because the VM may still hold memory for cache and the host may not reclaim it instantly. If Windows needs it now, shut down WSL. If Windows is fine, don’t panic over a number.

4) Does wsl.exe --shutdown delete anything?

No. It terminates WSL instances. Your files and distro state persist on disk. You’ll lose running sessions and any in-memory state, like you would after a reboot.

5) Should I set swap to 0?

Sometimes. If you prefer failing fast (OOM) over slow thrash, disabling swap can be defensible. For most developers, a modest swap is a safety net. If you disable it, be prepared for abrupt process kills under pressure.

6) What’s a sane processors value?

Half your cores is a good default. If you have 8 cores, give WSL2 4. If you have 16, give it 6–8. If you’re doing heavy parallel compiles and Windows is otherwise idle, raise it. If you care about UI responsiveness, cap it.

7) Is working in /mnt/c slower than in the Linux filesystem?

Typically, yes—especially for workloads with lots of small file operations (node_modules, Rust target dirs, container layers). Keep heavy build trees inside the distro filesystem for performance and fewer weird edge cases.

8) I use Docker Desktop with WSL2. Should I tune Docker or WSL?

Start with WSL2 because it’s the hard ceiling for the VM. Then tune Docker workloads (prune images, adjust compose replicas, set container memory limits) to stay inside that ceiling.

9) Can I set different limits per distro?

.wslconfig is global for WSL2 VM behavior. If you need per-distro isolation, you’re in “use separate VMs or different tooling” territory, not just WSL2 knobs.

10) How do I know if my problem is memory or disk?

Look for swap activity and I/O wait. Inside WSL, swapon --show tells you if swap is used; vmstat shows wa and swap in/out. If wa is high and swap is active, disk is now the bottleneck.

Next steps that actually stick

If WSL2 is eating your RAM, don’t treat it like a spooky Windows bug. Treat it like what it is: a VM running a real OS with real caching behavior. Then do what adults do in production systems: set budgets, measure, and respond to pressure early.

1. Pick a budget today: set memory and processors in .wslconfig and restart WSL.
2. Validate with evidence: confirm /proc/meminfo and nproc match your intent.
3. Watch for swap and I/O wait: if you see them during normal work, either raise the cap or reduce the workload.
4. Stop idling heavy services: Docker/Kubernetes should be a deliberate choice, not a background lifestyle.
5. Use shutdown as a tool, not a crutch: it’s a great emergency lever, but limits are the long-term fix.

Once you’ve done that, WSL2 becomes what it’s supposed to be: a solid Linux environment on Windows. Not an uninvited roommate with strong opinions about your memory budget.