Open LordMonoxide opened 5 years ago
Same here with Docker running on Ubuntu 18.04
Thanks for opening the issue. We have a fix for this in the works.
After moving to WSL2, VmMem seems to be constantly pegging my CPU. Please see attached screenshots.
Anything I can do to help your team troubleshoot?
Relevant details:
After moving to WSL2, VmMem seems to be constantly pegging my CPU. Please see attached screenshots.
I'm experiencing this too. It happens every time I run wsl after some elapsed time (varying from minutes to hours). It continues regardless of what's running in wsl, and I need to issue a wsl --shutdown
to stop it.
Windows insider build: 18922.1000 Linux distro: 18.04
I assume this really belongs in a new issue, but wanted to group my comment with that of @mithunshanbhag so I'll leave it here.
Hi, Same problem here. Lots of memory consumption with WSL2, nodejs app and VS Code with Remote - WSL while very low consumption in WSL1 with the same tasks.
Same issue on Win build 18950
@benhillis - Do we have a rough ETA on the fix? I'm actually hitting OOM issues on a machine with 32 gigs while just running a normal ninja build that should succeed.
Build 18955
@zachChilders - ETA on this one is a bit hard unfortunately. Certainly before WSL2 ships to non-insiders.
Can confirm this on 18963 as well. WSL 2 ate most (29GB+ of 32GB) of my RAM after less than 15 minutes of uptime for no good reason; all I've done is a rsync from the host NTFS volume to the ext4 volume, and an apt-get update
.
I can confirm the same issue on Microsoft Windows [Version 10.0.18963.1000]
C:\Users\david_d>wsl -l -v NAME STATE VERSION
I at the time was running gdb
how about a workaround? this just started happening for me (with 18965) and it has effectively killed my WSL 2 environment
Depending of your usage, nocache utility can be used as a workaround to greatly reduce WSL 2 memory consumption, especially if whatever you're running inside it does a lot of filesystem operations...
does nocache follow children? I could start my shell with "nocache"...
Haven't tried, but if I understood how nocache works correctly, it should...
thanks! nocache has changed my env from "completely broken" to "merely sucks"
thanks! nocache has changed my env from "completely broken" to "merely sucks"
Hi, could you explain how nocache should be used?
Hi @benhillis , any update on when a fix for this might be deployed to insiders? My 8gb of ram is really getting hammered by this issue... :(
I wrap compilations in nocache to keep limping along. wrapping nocache around a shell works, but breaks emacs. I've also ordered more RAM :-(
Sorry no firm timeline, certainly before WSL2 is out of Insider builds though.
Hi @benhillis , do you have a workaround you could recommend though ?
Well...I need it all day long and the memory consumption goes crazy after only a few minutes (using docker and a quite heavy stack: elastic search, lots of workers, some databases etc). So...not an option unfortunately. Maybe go back to linux while it is not fixed 😎
I am facing the same issue. Is there any workaround (except shutting wsl down) for this @benhillis ?
Not currently. For some additional context this change requires some changes to the Linux kernel that are in the process of being upstreamed. We will be integrating these changes into the WSL2 kernel as soon as we can.
Workaround: Create a %UserProfile%\.wslconfig
file in Windows and use it to limit memory assigned to WSL2 VM.
[wsl2]
memory=6GB
swap=0
localhostForwarding=true
This will still consume the entire 6GBs regardless of Linux memory usage, but at least it'll stop growing more than that.
Supported settings are documented here.
Hey @apostolos, got here from Google after running into the memory leak issue in my WSL2 instance. I'm on build 18970 and I created a .wslconfig file in my home directory as follows:
[wsl2]
memory=2GB
swap=0
localhostForwarding=true
but it doesn't seem to have any effect on the memory actually allocated by the instance - right now I'm running a compile job and it's at 5.6GB allocated and climbing. Do I have to reboot or do something else to get WSL2 to detect the configuration?
@apostolos @pikajude didn't work for me either. Ditched WSL 2 for now due to that.
@arthurgeron and @pikajude I created a .wslconfig
file this morning and it's been working for me. Did you run wsl --shutdown
to fully restart WSL?
@joemaller which build are you on? I've run wsl --shutdown
many, many times since creating the config file. Also what distro?
@pikajude Oh so many times... I'm running build 18970, with the unlabeled Ubuntu (18.04.3 LTS), clean installed yesterday
Same here :/ I wonder why yours works and mine doesn't.
@pikajude I'm not sure. I haven't done anything special. This is a clean Ubuntu 18.04.3 LTS installation (not upgraded from WSL1). OS Build is 18970.1005
You placed the .wslconfig
on your Windows home dir and not on Linux home right?
I've now capped it at 8GB, still works fine:
@apostolos I had place it in my Windows home config.... Will try again later today
@apostolos Yeah, I'm not very familiar with windows so I typed %UserProfile%
into Explorer and it took me to my home directory, so I created the file there at C:\Users\me\.wslconfig
. I did edit it with vim inside my WSL instance, so I wonder whether the line endings are different and if that interferes with it.
@pikajude I saved the file from Windows. Vim reports dos line endings:
".wslconfig" [noeol][dos] 4L, 52C
Okay, I fixed this. when I opened the wslconfig file in Notepad the encoding was set to UTF-16 LE, which maybe is the default encoding for text files? Anyway, I used File > Save As
and picked UTF-8 instead, and the setting now seems to be respected.
Using UTF-8 CRLF didn't work for me. I had to use the encoding DOS CP437 CRLF in VSCODE to get it working.
I'm facing the same issue when I build Docker images. Basically the more images I build the more ram is used. It looks like that WSL2 isn't releasing the memory after every build and so the usage keeps spiking.
I would like to note that even though the wslconfig
file does prevent my instance from consuming all my system's RAM, it's not actually releasing any unused RAM to the instance itself, which means all of my WSL processes eventually OOM given enough time. I've downgraded to WSL1 to work around this for now, even though the FS performance is nothing to write home about. Anxiously awaiting the fix! :)
In a laptop with 8GB of RAM, setting the WSL2 VM RAM to 4GB and increasing the swap partition with a SSD allowed me to perform operations that were failing before, just setting a lower WSL2 VM RAM.
Example %UserProfile%\.wslconfig
file
[wsl2]
memory=4GB
swap=16GB
localhostForwarding=true
Same thing happens in build 18990.
It happens with other hyper-v VMs or is wsl2 specific problem?
A fix is on the way, ETA ~2 weeks.
I ran this in my ubuntu environment and it seems to have cleared the cache. must sudo su first sync; echo 1 > /proc/sys/vm/drop_caches
** putting in on a cronjob as root works great too, seems to be allowing me to import a large db into my database via docker / mysql and have not run out of memory :)
will the fix come through Windows update in Fast Insiders mode. or is there another way?
I ran this in my ubuntu environment and it seems to have cleared the cache. must sudo su first sync; echo 1 > /proc/sys/vm/drop_caches
** putting in on a cronjob as root works great too, seems to be allowing me to import a large db into my database via docker / mysql and have not run out of memory :)
This did not seem to work for me; had to wsl --shutdown
instead.
[Build 18995]
It doesn't release, it just clears the cache so the vm can use it again. I have it running on a 1-minute cron job and it works. However, what it does is clear all caches and should not be run in production or where lots of cache is needed.
@pcottrell good to know -- this might explain why when building docker containers I get weird allocation issues from the underlying VM when trying to build the container.
@benhillis , any updated ETA for the fix?
does not appear to be a part of the 19002 insiders build
I've been running into this more and more where all memory will be consumed by the VM instance: this causes programs running into Windows to crash because they can't allocate more memory. Then, I attempt to reboot and the computer hangs trying to reboot and need to be forced off using the power button.
Your Windows build number: 18917
What's wrong / what should be happening instead: WSL 2 starts using huge amounts of RAM after a while, just using it like normal. At the moment I'm using phpstorm, and did a dump/load of a database.
Vmmem
is using 7 GB of my 16 GB of RAM and not returning any, even though Ubuntu is actually using much less. I have seen it grow until nearly 100% of my system memory is in use, and it will not release it until I shut down the WSL 2 VM.This may or may not be related to #4159