Language server leaks/eats 30+GB of RAM

[Ark-kun]

I'm not installing/updating any new packages. It just leaks lots of RAM over the time.

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
139520 avolkov 20 0 30.8g 24.1g 1452 S 1.0 38.4 254:31.27 /home/avolkov/.vscode/extensions/ms-python.python-2018.10.1/languageServer.0.1.60/Microsoft.Python.LanguageServer 
203203 avolkov 20 0 17.6g 9.4g 1540 S 1.0 14.9 99:36.68 /avolkov/.vscode/extensions/ms-python.python-2018.10.1/languageServer.0.1.60/Microsoft.Python.LanguageServer 

[jakebailey]

0.1.60.0 is an older build. The current stable release is 0.1.65.0 and should be getting downloaded by the extension. (Your extension is also last month's build, but the language server download should be independent.) I don't think we had any fixes specifically for memory usage between those releases, but you may want to try the newer build.

It would be helpful to know what project you're working on and if it's public such that we could test it. Your example in particular is interesting because it's high memory usage without the CPU usage being high.

[mungojam]

I had this at one point too today with 0.1.65.0.

We use pipenv with the PIPENV_VENV_IN_PROJECT=1 which means that we have a .venv folder in our workspace (though also in .gitignore). No idea if that might be the cause.

I've also noticed that ctrl+click on relative package references sometimes seems to spin for ever so perhaps that is causing an infinite loop that increases memory or something.

Unfortunately I can't share our code and I haven't got time at the moment to recreate it

[Honzys]

I can confirm the memory leak too. After few hours the memory usage is huge (something about 5GB), after reload it comes back to the normal usage. But using vscode actively (but I sometimes noticed that the memory usage incresased without doing anything) slowly increases the memory usage.

Don't know if this information will be helpful but I've noticed that in the output log was printed:

Reloading modules ....
done.
done.
done.

I was wondering why the LS reloads module so many times. The upper lines were interleaved with the linting output.

I am using venv, mypy.

If I notice anything else, I will edit this comment or add a new one.

[Honzys]

It seems to me that this issue was fixed with new version of python language server (actual version 0.1.72.0, previous version 0.1.65.0).
Running vs code 2 days straight and the memory usage didn't exceed 600MB of RAM.

It still needs further testing, but I just wanted to give this feedback, as I was happy seeing this issue (probably) gone in my case! Thank you very much!

[Drakezul]

While I do not know how to reproduce it I just peaked at 12GB again.
I have the 0.1.72 Version of the language server and python extension "2018.12.1"

The "Process Explorer" in VS Code only showed a memory usage of ~ 3.8GB for the language server, as compared to Windows 10 Task Manager that showed ~12GB

[Honzys]

Unfortunately the leaks are still here. But still dont know how to reproduce it.

[touhidulshawan]

I am using the latest version of languageServer 0.1.73. This python language server eats all my ram. For that, I can`t use vs code. Please tell me how to fix it

[chopin1998]

same... .vscode/extensions/ms-python.python 2018.12.1/languageServer.0.1.72/Microsoft.Python.LanguageServer

eat too much RAM, i just open two simple python file..

[koliyo]

Got the same thing, 25+ GB after a couple of days, not even using VS Code, just leaving it open.

[Honzys]

Strange thing is, that the python language server causes those memory leaks even if I haven't opened any .py file. It took 75% memory of my 16GB total memory.

[jakebailey]

When the language server starts, it begins analyzing every file within the workspace, which means that there won't be any difference between opening a file and not opening a file.

Without an example codebase, this is very hard to pin down. If you're also seeing CPU usage during that time, then it may be the case that the analysis isn't stopping, continuing to use more memory as it grows type information (which is #495 and #479).

Know that like #495 and #479, the memory usage issues should be handled with our new analysis approach. See Mikhail's comment here for more info: #479 (comment)

The analysis approach as a whole will be different, and the files you open will impact what gets analyzed (versus analyzing unopened files that may not be referenced).