WSL2 on limited RAM: vmIdleTimeout=-1 still suspends instances, and memory isn't released — best practice for a many-long-lived-process workload?

[iszzu80-dev]

Running a workload of ~13 long-lived Node.js processes (an AI-agent system) inside a single WSL2 distro on a 16 GB Windows host (WSL sees ~7.4 GB usable). Two related problems — hoping others have hit these and found a supported approach.

1. Keep-alive / suspend. %USERPROFILE%\.wslconfig has:

[wsl2]
vmIdleTimeout=-1

…yet instances/services still get suspended after a while (matches the reports in #13291 and #8659). Our current workaround is a PowerShell loop that keeps a process alive. Is there a supported way to keep a long-running server-style workload alive, or is the keep-alive loop still the accepted answer? Does adding instanceIdleTimeout=-1 under [general] alongside vmIdleTimeout=-1 help?

2. Memory pressure. WSL2 doesn't release RAM back to Windows, so MemAvailable creeps down and eventually the Linux OOM killer fires — which on our low-RAM host has cascaded into host-side instability. We're mitigating with:

[wsl2]
memory=11GB
swap=8GB

[experimental]
autoMemoryReclaim=gradual

Questions:

• For a many-long-lived-process workload on limited RAM, is autoMemoryReclaim=gradual the current best practice, and does it interact badly with the suspend / keep-alive behavior above?
• Any recommended swap / memory sizing rule of thumb for this kind of workload?

Thanks. Kernel is 6.x microsoft-standard-WSL2; happy to share more detail.

[Feng Wang (chemwolf6922)]

For 1.
Yes please use instanceIdleTimeout=-1 for this purpose. This parameter disables the distro auto shutdown timer. The vmIdleTimeout=-1 is not needed. As it's for the VM auto shutdown. Which only starts counting after all distros are terminated.

For 2.
If you are facing OOM. The memory reclaim won't help. The memory reclaim can only work on reclaimable ram. If the OOM killer is triggered, there is none. Increasing RAM allowance and swap is the correct approach. I'll also suggest investigating why that "AI-agent system" is eating all the RAM.