Skip to content
This repository was archived by the owner on Apr 14, 2022. It is now read-only.

Unexpected and uncontrolled high CPU load #1608

Closed
jkpubsrc opened this issue Oct 1, 2019 · 6 comments · Fixed by #1841
Closed

Unexpected and uncontrolled high CPU load #1608

jkpubsrc opened this issue Oct 1, 2019 · 6 comments · Fixed by #1841

Comments

@jkpubsrc
Copy link

jkpubsrc commented Oct 1, 2019

(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.

@MikhailArkhipov
Copy link

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.

@mungojam
Copy link

mungojam commented Nov 7, 2019

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:

pandas
sqlalchemy
numpy
cx-oracle
diskcache
flask
flask-cors
python-dotenv
waitress
cachetools
pyodbc
pythonnet

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:

image

@mungojam
Copy link

mungojam commented Nov 7, 2019

The log seems to be in an infinite loop of this:

[Info - 13:42:10] User search paths:
[Info - 13:42:10] Reloading modules...
[Info - 13:42:12] GetCurrentSearchPaths C:\Users\mark\source\repos\Our-Project.venv\Scripts\python.exe
[Info - 13:42:15] Interpreter search paths:
[Info - 13:42:15] c:\users\mark\source\repos\our-project.venv\lib
[Info - 13:42:15] c:\users\mark\source\repos\our-project.venv\scripts
[Info - 13:42:15] c:\programdata\anaconda3\lib
[Info - 13:42:15] c:\programdata\anaconda3\dlls
[Info - 13:42:15] c:\users\mark\source\repos\our-project.venv
[Info - 13:42:15] c:\users\mark\source\repos\our-project.venv\lib\site-packages
[Info - 13:42:15] c:\users\mark\source\repos\our-project.venv\lib\site-packages\win32
[Info - 13:42:15] c:\users\mark\source\repos\our-project.venv\lib\site-packages\win32\lib
[Info - 13:42:15] c:\users\mark\source\repos\our-project.venv\lib\site-packages\pythonwin

@jakebailey
Copy link
Member

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).

@jkpubsrc
Copy link
Author

jkpubsrc commented Dec 2, 2019

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.

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!

@MikhailArkhipov
Copy link

File watch turned off by default in #1841.
LS 0.5.10+

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants