watcherService: CPU usage rising with number of files in project #864
Comments
|
We switched the file watching by polling in WSL1 (non-VM mode) to workaround the WSL issue that non-empty folders are locked and can not be renamed when observed by inotify. While it's clear that that comes at the cost of performance our testing so far looked good. I will investigate what we can do to improve the performance. Right now the polling interval is 1s and things are not configurable. By default we exclude the node_modules folder from being watched. I'm not familiar with the 'eggs' folder. Can it be excluded from watching? |
|
microsoft/vscode#76303 (comment) I am also experiencing this issue now. It is causing my editing experience to have noticeable lag. |
@aeschli, thanks for the explanation. Does that mean that this won't be a problem anymore in WSL2, because you can go back to inotify?
I didn't know about
They are pretty much comparable to So I guess, yeah, they don't need to be watched upon.
After setting {
"files.watcherExclude": {
"**/eggs": true,
"**/node_modules": true,
"**/parts/omelette": true,
},
}the To be honest, I don't think that I should have to, though. I shouldn't have to configure an internal implementation detail of my IDE for each project I'm using it with, just to keep it from eating all my battery and driving the fan to 11. Of course I understand that not being able to move/rename files/directories because they're being watched by inotify isn't cool either. Does this apply to rename operations from within WSL too, or just when working with the files from within the Windows host? If it's the latter, then I wonder how many WSL users are really affected by it. I, for example, have my projects only inside WSL, not somewhere under |
|
@scy Yes, this only applies to WSL1. WSL2 uses the regular file watcher Yes, agree, adding a exclusion pattern is just a workaround, we don't want that regular users have to do anything. Yes, I'm working on making this configurable. |
|
I published a new remote WSL extension with a larger polling interval (5s) This requires the latest VSCode insiders... ( |
|
Thanks for the quick release. The larger polling interval doesn't seem to change CPU usage for me at all, but I can confirm that setting
You can't move/rename directories inside of WSL (i.e. those not below For my use case, this issue is kind of resolved with the workaround, but I leave closing it up to the VS Code Remote team, maybe you folks want to keep it around for a bit longer. Thanks again! |
|
Thanks for the feedback.
The default is |
Issue Type: Bug
When I started VS Code Insiders from WSL today in a Plone (Python) project of mine, I noticed that a
nodeprocess started using around 55% of my 8-core i7 system a few seconds after startup and would not stop. That process is running inside of WSL, not on the host. (It appears in the Windows task manager though, of course.) Here's what I already did, trying to debug this:c7d83e5) with the most recent Remote WSL available (0.38.0). On startup, there's a high-CPUnodeprocess, but it stops creating significant CPU load after about 10 to 20 seconds.rsyncto mirror the project to the host system and run VSC Insiders there. No issues, not even the shorter CPU burst usage I had noticed in my VSC Stable test from above.rsyncthe project dir to/tmp, remove.gitand start VSC Insiders again. Same issue, so it's not Git-related.node_modulesoutside of the project directory, so that VSC can't see it anymore. No change.eggstoo. Issue goes away. Interesting.eggs(find . -not \( -type f -o -type d \)), like symlinks. None found. So it's not just recursive symlinks. There can't be any hard links, since this directory was rsynced with-rtlfrom the original before.eggsand move about ⅓ of the original directories back in it (eggscontains about 33,000 files and (sub)directories). Issue reappears, but it's now using only about 15% CPU constantly instead of 55%.for d in $(seq 0 9); do mkdir -p $d; done; for i in $(seq 1 10000); do touch $((x % 10))/file-$i.txt; done). Issue appears, again with lower constant CPU usage (around 15%).By now, I think that some interaction between the WSL extension and the newer VSC version leads to elevated CPU usage of the file watcher process. This is my
ps fauxon the 10k files directory I've created in the last step:As you can see, the
--type=watcherServiceprocess is eating excessive amounts of CPU. It's not a child of--type=extensionHost, but a sibling. You can also see it incode-insiders --status:Curiously, in my real project directory, the process does not show up in
code-insiders --status, but instead the high CPU usage is attributed to theremote agent. No idea why that is.code-insiders --statuslooks like this there:While the high-CPU process is running, it starts with using about 220 MB RAM, slowly rises up to 280 MB over the course of about 40 to 60 seconds and then starts again at 220 MB. If I'd have to guess, this looks like an initial indexing run repeating over and over to me.
Let me know if you need any more information. For now, I think I'll use VSC Stable to continue working until there's a solution.
Extension version: 0.38.5
VS Code version: Code - Insiders 1.36.0-insider (fe0c3e785c22c3ed2d5caa7178488c92d62bdb08, 2019-06-28T12:34:35.956Z)
OS version: Windows_NT x64 10.0.18362
Remote OS version: Linux x64 4.4.0-18362-Microsoft
System Info
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_deferred_display_list: disabled_off
skia_renderer: disabled_off
surface_synchronization: enabled_on
video_decode: enabled
viz_display_compositor: disabled_off
webgl: enabled
webgl2: enabled
The text was updated successfully, but these errors were encountered: