See the following GitHub issue for the full context: WSL 2 consumes massive amounts of RAM and doesn’t return it. A big thanks to Apostolos Tsakpinis for pointing out how this can be done. This is no longer an issue now that WSL 2 supports memory reclamation.įortunately, we can customize WSL 2 to limit the number of CPU cores, memory usage, swap space, and more. In older versions of WSL 2, this was especially bad because it wouldn’t release memory to the host machine until WSL shut down completely, so long-running processes could continue to consume memory over time.

Your machine may become sluggish as it struggles to run resource-hungry host processes like Google Chrome or your favorite IDE alongside VM processes. Whatever the case may be, if your machine doesn’t have enough memory to begin with, then you’ve probably seen some noticeable slowdowns due to WSL 2. Since I’m running a Windows 10 build that’s older than 20175 at the time of this writing, my WSL reserves 80% of my host RAM (8 GB), which in this case is 6.4 GB. On my system, that shows the following output, where each number is in gigabytes: total used free shared buff/cache available You can check how much memory and swap space are allocated to WSL using the free command from within a WSL distribution: free -h -giga On builds older than 20175, WSL could consume up to 80% of your host RAM. On machines running build 20175 or higher, RAM is limited to either 50% of your total memory or 8GB, whichever happens to be smaller. According to Microsoft’s documentation, the amount of RAM that gets allocated to WSL depends on your Windows build number. This special process represents all the resources consumed by your Linux VM while WSL is running. If you’ve ever opened up Task Manager while WSL 2 was running on a Windows machine, you’ve probably noticed a process named vmmem hogging a sizable chunk of your memory and slowing down your machine.

Monitor ram usage ubuntu