-
Notifications
You must be signed in to change notification settings - Fork 133
Unexpected and uncontrolled high CPU load #1608
Comments
Normally there is only one process. Multiple processes may be spawn if you have multi-root workspace, this is controlled by the Python extension, not LS. In order to identify possible issue please provide list of packages your code imports, especially large ones. Thanks. |
This is affecting me too and I'm not using multi-root workspaces. I'm importing various internal packages with pipfile (using a local .venv folder within the workspace). The external libs are:
At the moment it is only running one process. Perhaps it was when I had more VS Code windows open that there were about 4 of them: |
The log seems to be in an infinite loop of this:
|
Could you open a new issue with the info we request in our issue template? This issue is a month old and may not be related. Perhaps I'm misunderstanding, but I don't think you're saying you end up with more than one LS (and the screenshot is just VS Code's own child processes, stuff like the renderer, extensions, etc, versus the singular LS). |
I am not using any multi-root workspaces. I am running VSCode on a single user account. I am frequently running multiple instances of VSCode in parallel as for modularization purposes I sometimes make (small) changes to multiple modules in parallel. It seemed that a separate language server had been started for every single instance of VSCode. I can't check on this any more as I was forced to deactivate the language server completely because of this bug and am now going without it. That's not very convenient but more convenient than having the language server produce excessive CPU loads. There is no point in providing you with a list of packages. First of all, you won't be able to replicate the behavior exactly as I saw it on my machine, since I'm using some (smaller) packages that aren't publicly available. Second you can set up a system yourself by downloading some Python packages if you like: There are tens of thousands of packages available. You might want to try some machine learning and language processing frameworks as a starting point, going to roughly about 250 packages in total (including all dependencies). However, no server should be implemented in such a way that the user cannot control its behavior. This seems to be a fundamental design flaw. If the language server would rebuild some kind of index - I guess that's what you are thinking - it should be controllable by the user. If I try to use this server on a battery-powered notebook as described above, it's completely unthinkable that the user can't control this behavior. I think you should take a look at your general server design. Especially if you tell me that there should be just one process while I saw multiple ones, one for every project instance. And especially as this is not the first time this issue arises: There seem to be quite some reports about such kind of behaviour - for years! |
File watch turned off by default in #1841. |
(Moved from vscode to this issue list as the problem still seems to persist to some extent. Here's the original issue text.)
I updated Visual Studio Code to version 1.83.1 (which is currently the most recent version). I'm running this on a Linux notebook. Today suddenly multiple processes named Microsoft.Python.LanguageServer were consuming all CPU power available. After letting it run for maybe 5 minutes I killed the processes as they seemed to utilize all CPU cores available with all negative consequences involved: Generating an intense amount of heat in the CPU - and the CPU fan went crazy as it probably never has done before.
I can only guess whatever the root cause for this behaviour is as I don't know how to debug Visual Studio Code. This might be a duplicate to issue #2664. This issue is marked as "resolved" in 2018 - which apparently is not the case.
Whatever the root cause might be, this needs to be seen as a bug. It is unacceptable that a simple IDE makes use of such an extensive amount of CPU power, especially in such a way, that the user has not direct control about this.
The text was updated successfully, but these errors were encountered: