{"id":2313,"date":"2021-03-01T11:00:00","date_gmt":"2021-03-01T10:00:00","guid":{"rendered":"https:\/\/www.nico-maas.de\/?p=2313"},"modified":"2021-02-24T08:29:09","modified_gmt":"2021-02-24T07:29:09","slug":"wsl2-win10-limit-resource-consumption-of-wslv2","status":"publish","type":"post","link":"https:\/\/www.nico-maas.de\/?p=2313","title":{"rendered":"[WSL2\/Win10] Limit Resource Consumption of WSLv2"},"content":{"rendered":"\n

Windows Subsystem for Linux 2 has a big problem called \"Vmmem\" - it is the process WSL uses to allocate RAM for usage within its user context. That itself is all fine, however, there are many known issues <\/a>that show that even after closing your e.g. Debian session, this memory is not returned to the system. This is also valid for usage of Docker for Windows within the WSLv2 context (meaning using Docker in the \"new-style\" install, not with the old HyperV machine).<\/p>\n\n\n\n

The easy way to mitigate the pain (meaning RAM-being eaten up faster than a Chrome Engine spinning up ;)) is to just shutdown the WSL engine after usage, which you can do by opening up a Powershell or CMD with admin rights and enter<\/p>\n\n\n\n

wsl --shutdown<\/code><\/pre>\n\n\n\n
This will shutdown WSL until you start it manually again. (Thanks smigel<\/a>!)<\/p>\n\n\n\n
A better way to work with this is to create a .wslconfig<\/a> in your Windows User directory. Here is a short example.<\/p>\n\n\n\n
[wsl2]\n memory=2GB # Limits VM memory in WSL 2 to 2 GB\n processors=2 # Makes the WSL 2 VM use two virtual processors\n swap=0 # Do not use a swap file<\/code><\/pre>\n\n\n\n
Anyway, the issue <\/a>is still open and not yet fixed, even though a fix was promised on 17.06.2019<\/a>. Worse, Microsoft locked the issue in July 2020 for \"spam\". Talking about bad customer experience...<\/p>\n