With the official release of the Windows 10 2004 Update on May 27th, WSL2 is now available without the use of the Windows Insider Preview version: tada:
However, when using WSL2, there is a problem that the memory usage of the process called Vmmem keeps increasing and the memory of the Windows host is exhausted. And this problem remains unresolved after the official release.
NOTE: It is OK with a rough understanding that you can check "CPU and memory consumed & reserved by the entire Hypver-V virtual machine of WSL2" in the Vmmem process running on the Windows host.
The microsoft / WSL issue has been open for nearly a year, and although Microsoft is aware of the problem and is working on it, it has not yet been addressed.
https://github.com/microsoft/WSL/issues/4166
Important updates regarding this issue will be added here. We will send a change notification at the time of update when this problem is fundamentally resolved.
--2020/06/03 --WSL development members say that the cause of this problem is due to the Linux file cache (Link), provisional The solution is to fix the memory size (Link), and the problem is currently being addressed (Link). //twitter.com/craigaloewen/status/1267867503394295809? s = 20))) is posted on Twitter.
By fixing the memory size of WSL2, you can prevent the memory exhaustion of the Windows host. If you are interested in the cause, please refer to it later.
Make the following settings in the config of % USERPROFILE% \ .wslconfig.
--% USERPROFILE% points to your home directory, such as C: \ Users \ taro.
--If the config does not exist, create it.
--After setting, restart WSL2 or restart the OS.
[wsl2]
memory=6GB
swap=0
--For memory, specify the maximum memory size allocated by WSL2. Change the memory size value according to the installed memory of the PC and the intended use of WSL2. By the way, the default value when not specified is 80% of the installed memory of the PC **.
-(Personally recommended) Set swap to 0 to disable swap.
--If swap is disabled, WSL2 may behave strangely as soon as it actually runs out of memory. However, instead of using SSD etc., it is possible to prevent the occurrence of a large amount of swap In / Out, so it is possible to avoid shortening the SSD life due to a large amount of writing. Consider whether to set it with the trade-off in mind.
I think that one of the advantages of WSL2 is that it can be used without setting the upper limit of the memory size, so this provisional measure is painful, but it can not be helped. I want you to improve it in some way as soon as possible.
In the Issue, it is pointed out that the following characteristics of Linux and WSL2 are combined to cause problems.
--On Linux, actively place the file cache in memory when accessing files (increased buff / cache usage in the free command). Basically, the file cache is kept until the file is deleted or the memory becomes insufficient so that the process cannot secure the memory. --WSL2 dynamically increases or decreases the memory size of the virtual machine according to the memory usage of Linux on the virtual machine. --Of course, the memory size of the virtual machine should be larger than the memory usage of Linux.
Due to each characteristic, when accessing a large amount of files, libraries, Docker images, etc. at the time of development etc., a large amount of memory is secured mainly in the Linux file cache, and WSL2 increases the memory size of the virtual machine accordingly. To go. Since WSL2 increases the memory size of the virtual machine, Linux judges that "there is still enough memory" and accumulates more file cache, causing a vicious cycle.
As a result, the memory of the Windows host will be exhausted relatively easily not only on the PC with 16GB of memory but also on the PC with 32GB of memory.
The following is the memory usage of Vmmem and Linux in the environment where the memory size of WSL2 is fixed at 6GB. The memory usage of Linux is confirmed by the result of the free command. Please refer to it as a rough guide.
# -Vmmem memory usage=3.WSL2 Linux memory usage at 5GB
# -Linux memory usage=3.1GB(Inside, buff/cache usage is 2.6GB)
$ free -h
total used free shared buff/cache available
Mem: 5.8G 479M 2.7G 1.2M 2.6G 5.1G
# -Vmmem memory usage=1.7GB
# -Linux memory usage=0.6GB(Inside, buff/cache usage is 183MB)
$ free -h
total used free shared buff/cache total used free shared buff/cache available
Mem: 5.8G 457M 5.2G 1.2M 183M 5.2G
The following use cases are prone to host memory exhaustion. This problem is more likely to occur, especially when these use cases are combined.
--Using Visual Studio Code + Remote Extension (WSL) --I'm using Docker Desktop WSL2 --Developing with a large code base
The above combination is likely to be one of the mainstream of "Unix / Linux environment development on Windows", but it is ironic that the combination is likely to cause this problem.
Introducing the provisional measures that do not fix the memory size of WSL2. All of them need to be executed manually, and some ingenuity is required for automatic operation, so we do not actively recommend them.
Basically, fixing the memory size is the most effective, but if you want to keep the memory size variable, you can suppress the symptom to some extent by dropping the Linux cache regularly.
sudo sh -c "echo 3 >'/proc/sys/vm/drop_caches' && swapoff -a && swapon -a"
However, since systemd and cron are not running in WSL2, fixing the memory size is the easiest considering that preparations are required.
If you restart WSL2 once referring to the information in the URL below, the WSL2 virtual machine will start up with the file cache etc. cleared.
By the way, WSL1 and WSL2 are basically the same for operations such as restarting WSL.
The reference URL is mainly for those who want to go a little deeper into memory management of WSL2 and Linux. (I also added what I received in the comment section)
-Issue of this issue ――Currently, there are active comments, and I think that related Pull Requests and new provisional measures will be exchanged in the future.
memory setting is 80% of host memory.
-See the memory management of Windows Subsystem for Linux 2 in detail
--I haven't touched on the Linux file cache, but it contains information about memory management for WSL2 and Vmmem, including verification.
-Basics of Linux and memory that I can't hear anymore & detailed usage of vmstat
--Basics around Linux memory including file cache etc.
-Remaining memory is decreasing! What is the cause !?
--This is also the basics around Linux memory including file cache etc. It may be easier to imagine because the figures are a little rich and easy to see.Recommended Posts