process manager: CPU statistics are much lower than actual

[axetroy]

Issue Type: Bug

The process management of vscode shows that the CPU usage is almost 0.

But in fact, it takes up most of the CPU.

Even higher than Chrome’s occupancy.

VS Code version: Code - Insiders 1.54.0-insider (c47da720f351455681978a48edc4d9a0d095ea0e, 2021-02-24T12:22:35.736Z) OS version: Darwin x64 20.1.0

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz (4 x 1800)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
webgl: enabled
webgl2: enabled| |Load (avg)|38, 48, 52| |Memory (System)|8.00GB (0.47GB free)| |Process Argv|| |Screen Reader|no| |VM|0%|

Extensions (72)

Extension|Author (truncated)|Version ---|---|--- better-comments|aar|2.1.0 commit-message-editor|ada|0.15.3 vscode-nginx-conf|ahm|0.1.3 preview-pdf|ana|0.0.2 z-reader|aoo|1.0.3 s4|axe|0.1.1 vscode-auto-schema|axe|0.2.2 vscode-changelog-generator|axe|1.0.0 vscode-comment-autocomplete|axe|0.4.2 vscode-gpm|axe|2.6.1 vscode-http-proxy|axe|0.1.3 vscode-movie|axe|0.5.0 vscode-npm-import-package-version|axe|0.8.1 vscode-open-in-browser|axe|1.0.0 vscode-static-server|axe|0.3.1 github-markdown-preview|bie|0.0.2 markdown-checkbox|bie|0.1.3 markdown-emoji|bie|0.1.0 markdown-preview-github-styles|bie|0.1.6 markdown-yaml-preamble|bie|0.0.4 better-toml|bun|0.3.2 vscode-eslint|dba|2.1.14 docs-yaml|doc|0.2.6 xml|Dot|2.5.1 gitlens|eam|11.2.1 EditorConfig|Edi|0.16.4 prettier-vscode|esb|5.9.2 go|gol|0.22.1 vscode-nginx-conf-hint|han|0.1.0 comment-translate|int|1.4.2 vscode-placeholder-images|Jak|0.1.0 vscode-colorize|kam|0.10.0 git-graph|mhu|1.28.0 dotenv|mik|1.0.1 vscode-language-pack-zh-hans|MS-|1.54.0 csharp|ms-|1.23.9 vscode-dotnet-runtime|ms-|1.0.0 python|ms-|2021.2.582707922 vscode-pylance|ms-|2021.2.3 jupyter|ms-|2021.3.593162453 remote-containers|ms-|0.161.0 remote-ssh|ms-|0.64.0 remote-ssh-edit|ms-|0.64.0 remote-wsl|ms-|0.54.0 vscode-remote-extensionpack|ms-|0.20.0 vscode-typescript-tslint-plugin|ms-|1.3.3 vetur|oct|0.32.0 indent-rainbow|ode|7.5.0 vscode-versionlens|pfl|1.0.9 material-icon-theme|PKi|4.5.0 material-product-icons|PKi|1.0.1 quicktype|qui|12.0.46 nginx-formatter|ray|0.0.13 vscode-yaml|red|0.15.0 vscode-sort-json|ric|1.19.2 rust|rus|0.7.8 extension-update-reporter|ryu|1.0.3 bash-beautify|sha|0.1.1 vscode-nginx|sha|0.6.0 trailing-spaces|sha|0.3.1 mdx|sil|0.1.0 svg-preview|Sim|2.8.3 code-spell-checker|str|1.10.2 luna-paint|Tyr|0.2.0 errorlens|use|3.2.4 vscodeintellicode|Vis|1.2.11 vscode-vlang|vla|0.1.7 vscode-icons|vsc|11.1.0 vscode-todo-highlight|way|1.0.4 vscode-nginx|wil|0.7.2 markdown-all-in-one|yzh|3.4.0 vscode-caddyfile-syntax|zam|1.0.4 (1 theme extensions excluded)

[RMacfarlane]

Interesting, the PIDs of these two processes do not show up in the VSCode Process Explorer at all. If you still see this problem, can you try changing the MacOS Activity Monitor with "View > All Processes, Hierarchically"?

[axetroy]

https://user-images.githubusercontent.com/9758711/109244687-1747db00-781a-11eb-821e-850e2ca4c004.mov

This is a video I recorded. It can be seen that the CPU counted by vscode is not consistent with the CPU counted by the system monitor.

And my fan has been spinning frantically, indicating that the CPU is not idle like the vscode statistics.

[RMacfarlane]

Thanks! It looks like there's an orphaned process that is causing the high CPU usage. @alexdima Have you investigated this kind of problem in the past or know someone else on the team who has? I guess as a first step, @axetroy, could you try running with extensions disabled and see if you still see this behavior?

[alexdima]

cc @bpasero @deepak1556

@RMacfarlane the next steps would be to try to find out which of our processes is becoming orphaned, by looking at the problematic process command line arguments.

Also, it would be cool if the process explorer would try to find / render orphaned processes too.

[deepak1556]

Yup I would start with command line to identify which child process got orphaned.

@axetroy can you provide the output of ps -p <PID> | xargs and also take a sample of the process using the following command,

xcrun xctrace record --template 'Time Profiler' --output /tmp/code.trace --attach <PID>

[axetroy]

@deepak1556

https://user-images.githubusercontent.com/9758711/109306490-35ddbe80-787a-11eb-886a-7a1ef6bf7175.mov

Here is the pid information

 1903 ??        20:30.21 /Applications/Visual Studio Code - Insiders.app/Contents/Frameworks/Code - Insiders Helper (Renderer).app/Contents/MacOS/Code - Inside

from now, I don’t know why it has this isolated process

But I guess that the process may not be killed when the window is reloaded.

https://user-images.githubusercontent.com/9758711/109306857-bc929b80-787a-11eb-9871-129daf72e86c.mov

This process will not be killed, and will remain in place, occupying 30%-70% of the CPU

[deepak1556]

@axetroy please pipe the ps output to xargs otherwise it will be cut off to the terminal width, in the above output we don't see the command line arguments because of it and it is important to know the arguments for us to identify which process it is.

But I guess that the process may not be killed when the window is reloaded.

that is a possible scenario, but I haven't been able to repro this.

[axetroy]

@axetroy please pipe the ps output to xargs otherwise it will be cut off to the terminal width, in the above output we don't see the command line arguments because of it and it is important to know the arguments for us to identify which process it is.

But I guess that the process may not be killed when the window is reloaded.

that is a possible scenario, but I haven't been able to repro this.

PID TTY TIME CMD 17713 ?? 1:00.84 /Applications/Visual Studio Code - Insiders.app/Contents/Frameworks/Code - Insiders Helper (Renderer).app/Contents/MacOS/Code - Insiders Helper (Renderer) /Users/axetroy/.vscode-insiders/extensions/dbaeumer.vscode-eslint-2.1.14/server/out/eslintServer.js --node-ipc --clientProcessId=17644

oh! This seems to be a problem with eslint.

Thank you for your help. Should this issue be closed? Or vscode can guarantee that the extension cannot have orphaned processes

[deepak1556]

vscode can guarantee that the extension cannot have orphaned processes

Not possible with the current implementation, as extensions are free to choose how they spawn the process using node.js child_process api.

Should this issue be closed?

Will let @alexdima or @RMacfarlane decide on that, let me know if I can help further.

[alexdima]

We cannot control what extensions do w.r.t. their spawned processes, so I suggest we continue tracking in https://github.com/microsoft/vscode-eslint/issues/1191