Open StephaneKazmierczak opened 3 years ago
cc @aeschli @craigloewen-msft I've also been getting high Vmmem CPU usage in the last few weeks, and force quitting WSL seems to help mitigate it. I'm not sure if this could be upstream to WSL or Windows at all since I've been experiencing the higher CPU usage independent of using Remote-WSL.
This isn't something that we've seen yet filed on the WSL repro.
@bamurtaugh are you able to have a consistent repro for this? What Windows version are you using?
Unfortunately not very consistent @craigloewen-msft. I'm on Windows 10 Enterprise, 10.0.19043.
Maybe 2-3 weeks ago, I found that when I wasn't using my computer at night, the fan would go extremely high for at least 5-10 minutes at a time, at least 3 times a night. When I opened up my computer, I saw 100% CPU was being consumed, and the Antimalware service executable
and vmmem
seemed to be two of the main culprits.
Through online research I tried a variety of techniques:
wsl --shutdown
This happened for a few days, then it stopped. Then it happened for maybe another day a week or so later, then stopped, and I don't think I've encountered high CPU usage for another week or so. I tried to do quite a bit of digging online to see if this was a known issue (i.e. high CPU usage or consumption by these specific processes) in a recent Windows update, but I couldn't seem to find anything specific. Wanted to relay this in case it ends up being useful - otherwise it could be just me 🤷 (although I just got a new machine ~6 months ago).
Ok gotcha! Hmm well I'm on the latest builds and don't see this issue, so perhaps this is something that has been resolved, or is just a transient issue.
If you do see it again, before you run wsl --shutdown could you run htop
in your WSL instance and see if any WSL processes are using a lot of CPU? And take a look at your Task manager and see if the vmmem
process is high up on CPU usage? That will help us get a picture of what could be going on.
Other than that I hope it's transient and I'll keep an eye out!
Sounds good, thanks for the suggestions! I'll keep you posted if I run into this again and the outcome of these steps if I do.
Hello, sorry I completely forgot about this, I can't confirm but I think it may have been related to opening very big workspace with lots of repository and files. I was adding lots of repo for convenience into my workspace, some of them with lots of files [react stuff] when this was happening. I have stop doing that, just working on one small project at time and I haven't had the issue since.
@craigloewen-msft My computer's fan has been spiking recently again (on and off for a few weeks), so I wanted to provide the recommended info.
Task manager:
htop
from WSL instance:
I'm now on Windows 11. If you have any thoughts, would love to hear them!
Well looks like the vmmem is not using much CPU load from your screen shot, maybe if you could sort taskmanager by CPU and catch it when it is spinning high. If CPU and RAM don't go very high then you could check if there is a quiet settings in your power management software (on my thinpad it is call vantage) you can also try to undervolt the CPU a bit ( i am using Throttlestop FIVR settings) to save a few degrees.
The high CPU load seems to stem from the C/C++
extension's parsing of the workspace, which in turn has stalled an IntelliSense update (rendering it useless).
I think it may have been related to opening very big workspace with lots of repository and files. I was adding lots of repo for convenience into my workspace, some of them with lots of files
Much like @StephaneKazmierczak, my workspace is rather large (as evidenced by the 30k indexed files—and climbing). I'll try whittling it down 👍
Otherwise, try changing your "C_Cpp.workspaceParsingPriority"
and rip off the Band-Aid at your own pace, so to speak.
Edit: similar to closed issue #6835
sustained loads @ ~10% for COM Surrogate
and 3-5% for Vmmem
Same issue, but I only open two vscode windows.
So I have to configure 20G swap and 14G memory, but still not enough
[wsl2]
memory=14GB
processors=8
swap=20GB
Issue Type: Bug
Not sure from when it started, but I recently noticed high CPU usage related to this extension, it triggers ~ 25-40% usage from the "COM surrogate" process and about the same from "Vmmem" process. This CPU usage completely stops if I disable the wsl remote app or disconnect from wsl.
Extension version: 0.56.5 VS Code version: Code 1.57.1 (507ce72a4466fbb27b715c3722558bb15afa9f48, 2021-06-17T13:28:07.755Z) OS version: Windows_NT x64 10.0.19042 Restricted Mode: No Remote OS version: Linux x64 5.4.72-microsoft-standard-WSL2
System Info
|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz (4 x 2904)| |GPU Status|2d_canvas: enabledgpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|15.84GB (5.59GB free)| |Process Argv|--crash-reporter-id 5f564a54-8aac-4d61-a68a-1a5ee14df08a| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|WSL: Debian| |OS|Linux x64 5.4.72-microsoft-standard-WSL2| |CPUs|Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz (4 x 2903)| |Memory (System)|12.36GB (10.37GB free)| |VM|0%|
A/B Experiments
``` vsliv368:30146709 vsreu685:30147344 python383cf:30185419 pythonvspyt602:30300191 vspor879:30202332 vspor708:30202333 vspor363:30204092 pythonvspyt639:30300192 pythontb:30283811 pythonvspyt551cf:30311713 vspre833:30321513 pythonptprofiler:30281270 vshan820:30294714 pythondataviewer:30285071 vscus158:30321503 pythonvsuse255:30323308 vscorehov:30309549 vscod805cf:30301675 binariesv615:30325510 ```