RAM Consumption

[iddan]

Environment data

VS Code version: 1.18.1 (1.18.1)
Python Extension version: 0.8.0
Python Version: Python 2.7.10 (3.6 in venv)
OS and version: macOS Sierra 10.12.6

The extension process consumed up to 50GB of RAM

[DonJayamanne]

Please could you provide some more information on this.
What process was consuming the memory? (Vscode, python)
Were you using some special library/ environment in Python?
Were you debugging done application?
Were you using the application for a long time?

[iddan]

What process was consuming the memory? Python
Were you using some special library/ environment in Python? No
Were you debugging done application? No
Were you using the application for a long time? Yes

[DonJayamanne]

Thanks for the updated info,
one last question, is this something you experience quite often or was this something you experienced once?

[iddan]

Only experienced once

[e-cma]

I experienced similar problem - python eats whole memory
When i put cursor on function sometimes i see popup with information about this function, but sometimes i see just "Searching.." and then python starts to eat whole memory

VS Code version: 1.18.1
Python Extension version: 0.8.0
Python Version: Python 2.7.12
OS and version: Linux Mint 18.2

[DonJayamanne]

When i put cursor on function sometimes i see popup with information about this function, but sometimes i see just "Searching.."

This indicates there a problem with the built in language server (running in python).

@iddan @e-cma
Next time this happens, please could you go into the console window under Tools-> Toggle Developer tools menu and copy the contents of the console window.

Also, are any of you using any packages such as numpy, pandas or similar (a package that you believe might be considered large)?

[e-cma]

I looks completion.py eats more than 6 GB of ram.
Currently I have wxPython and OpenCV.

[Edit]
And this happen only in this project (based on python 2.7). In project with OpenCv based on python 3 there is no problem.

[DonJayamanne]

As I suspected this is an issue with the Jedi library (davidhalter/jedi#843).
That being said we're still packaging an older version of the jedi library in the extension.

[Yensan]

@DonJayamanne
thank you for this plugin, it is so convenient. But I find it will cause Windows system and VScode become a zombie (CPU MEM utilization burst), so I disable the plugin and use Pycharm community as substitute. That is so sad.
I use it in Win7, VS Code version: 1.18.1 (1.18.1), Python Extension version: 0.8.0, python 2.7 & 3.6 venv

[brettcannon]

@Yensan we're obviously sorry to see you go, but we do understand. Please stay subscribed to this issue so that you can stay abreast of any work we do towards fixing this so you can come back and try VS Code and the extension again.

[Yensan]

@brettcannon
sure. I use VScode every day. I did not uninstall Python plugin, just turn it down (If not, Win7 and VScode will be zombie)
VScode is one of my best tool. And Dev team of Microsoft is very nice guys.
Maybe detect python path is a bad idea. Because this will cause hardware high utilization, but, for VScode user setting env is the Elementary concept. I will choose py2 py3 py2.venv py3.venv by myself.

[ivlevdenis]

At me too completion.py eats all memory 8G, also a swap 😞

[ivlevdenis]

More info

di-erz@worklap:~$ ps aux|grep 9488
di-erz    9488  1.0 23.4 1830448 1790396 ?     S    10:14   0:19 /home/di-erz/projects/tgdump/venv/bin/python completion.py preview
di-erz@worklap:~$ cat /proc/9488/status 
Name:	python
State:	S (sleeping)
Tgid:	9488
Ngid:	0
Pid:	9488
PPid:	8598
TracerPid:	0
Uid:	1000	1000	1000	1000
Gid:	1000	1000	1000	1000
FDSize:	64
Groups:	4 24 27 30 46 113 128 999 1000 
NStgid:	9488
NSpid:	9488
NSpgid:	2525
NSsid:	2525
VmPeak:	 1835336 kB
VmSize:	 1830448 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	 1795472 kB
VmRSS:	 1790396 kB
VmData:	 1782848 kB
VmStk:	     180 kB
VmExe:	    3712 kB
VmLib:	    5892 kB
VmPTE:	    3596 kB
VmPMD:	      20 kB
VmSwap:	       0 kB
HugetlbPages:	       0 kB
Threads:	1
SigQ:	0/29449
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000001001002
SigCgt:	0000000180000000
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000
Seccomp:	0
Cpus_allowed:	f
Cpus_allowed_list:	0-3
Mems_allowed:	00000000,00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	6624
nonvoluntary_ctxt_switches:	2749

[philippefields]

Same issue here:
Ubuntu 16.04, VScode 1.18.1, python 2.7
Opened a project using wxPython + a small lib of my own : Completion.py eats up 7 Gb of RAM.
Unusable on my 4Gb i7 laptop, the swap goes crazy.

[roelandxyz]

I can also reproduce this problem when working with PyGobject.
To get auto-completion I generate a fake python package with https://github.com/strycore/fakegir
If I generate this without docs the completion works fine with a small delay. Gtk.py is then 307K.
When I generate this with docs the completion eats all memory and cpu and fails. Gtk.py is then 2.2M.
I have 16Gb RAM and run xubuntu 17.10 on a thinkpad T470.

On sublime text (anaconda plugin) this works without a problem.

Here a simple example. Try completion on 'Gtk.Wind' and cpu en mem is 100% used and it never works.

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk  # noqa

win = Gtk.Wind

[tzachshabtay]

I had to uninstall the extension due to this bug. It kills my machine whenever I open a python file from vs code. I currently use an alternative extension (https://marketplace.visualstudio.com/items?itemName=tht13.python) but as there's no debugging support there I desperately need this bug to be fixed.

[DonJayamanne]

@tzachshabtay I'm sorry to hear about this. We are currently looking at this space and will keep you posted. Rather than uninstalling the extension you could probably disable the extension in a specific workspace (this is a new feature introduced in the latest version of VS Code).

Finally, please could you confirm you have updated the extension to the latest 0.9.0 release. We have made some improvements around the performance of intellisense/autocompletion within the extension.

[tzachshabtay]

Reproduced with 0.9.1, vs code 1.19.0 (opening the first random python file triggered it). It reached 10 GB in less than a minute.

[ivlevdenis]

Also jedi uses a lot of disk space for cache...

[MikhailArkhipov]

Basically looks like Jedi has issues with a) recursive code and b) cache growth. If I hover over regular function, python process size increases by 500K-1MB. If I hover over recursive call, the process memory footprint can easily jump up by 20-30-40MB. Also, it seems to never go down, it appears the cache is never cleaned up for entries not accessed for a long time.

[mmaroti]

This is an issue for me on all recent version of VSCode and phytonVSCode on ubuntu 16.04 and 17.04. I can almost reliably trigger this when editing code containing GNURadio. Completion.py eats up more than 32 GB or RAM and makes the machine completely unusable. PLEASE make it possible to disable JEDI and completion.py so we can use the rest of the vscode-python plugin reliably!

[MikhailArkhipov]

As a workaround you can simply kill python.exe that is running jedi (command line contains completion.py). This will drop intellisense but the rest of the product would keep working.

I am trying to figure out what kind of code might be causing jedi to consume memory in a runaway manner. So far I haven't found the case. I mean, RAM usage increases with time, but it does not exceed few hundred megs for me. I'd like to find good repro and report it to jedi.

One possible workaround for us might be to monitor memory footprint and restart python process that is running jedi.

[brettcannon]

@mmaroti can you provide or point us directly at a repo and exactly what file to open that triggers the memory explosion for you?

[mmaroti]

You have to install GNURadio. I usually follow the installation steps outlined here to build it on my machine with all bells and whistles: https://gnuradio.org/doc/doxygen/build_guide.html, https://wiki.gnuradio.org/index.php/BuildGuide. However, there are prepackaged version for ubuntu: apt-get install gnuradio. This will get some older version, and I am not sure that will trigger the problem, but I suspect that it will!

To trigger the problem you need to edit python files that reference gnuradio modules. I would recommend this repo: https://github.com/gnuradio/gr-tutorial and edit with intellisense the python files. It takes around 30 minutes for me to trigger it, so it is not deterministic, but maybe you know how to trigger jedi reliably.

Let me know if you managed to reproduce the problem. If you do not, then I can set up a virtual machine and try to test it there.

[MikhailArkhipov]

Yes, working on it.

It may be just the fact that GNU Radio is complex. If jedi loads file with ~3000 lines memory grows by ~50MB. So if we request info on a function that is in a big file and calls another function in another big file and so on, each may cause memory to go up but tens of megs.

[mmaroti]

Indeed, GNU Radio is very complex and generates large python files (see below). I would be completely happy if I could disable intellisense and/or jedi within vscode-python.

As it is, I always keep a terminal with htop running so I can quickly switch to it and kill completion.py before the system becomes unusable. Killing it once is not enough, I think it is restarted. :(

mmaroti@maroti-dell:/usr/local/lib/python2.7/dist-packages/gnuradio$ ls -Sl find . -name "*.py" -print
-rw-r--r-- 1 root staff 801947 Oct 19 18:01 ./filter/filter_swig.py
-rw-r--r-- 1 root staff 764889 Oct 19 18:01 ./dtv/dtv_swig.py
-rw-r--r-- 1 root staff 660180 Oct 19 18:00 ./blocks/blocks_swig3.py
-rw-r--r-- 1 root staff 642872 Oct 19 18:01 ./trellis/trellis_swig1.py
-rw-r--r-- 1 root staff 617472 Oct 19 18:00 ./blocks/blocks_swig2.py
-rw-r--r-- 1 root staff 615302 Oct 19 18:01 ./analog/analog_swig.py
-rw-r--r-- 1 root staff 578503 Oct 19 18:00 ./blocks/blocks_swig5.py
-rw-r--r-- 1 root staff 559102 Oct 19 18:01 ./digital/digital_swig0.py
-rw-r--r-- 1 root staff 508484 Oct 19 18:00 ./blocks/blocks_swig1.py
-rw-r--r-- 1 root staff 451718 Oct 19 18:00 ./blocks/blocks_swig4.py
-rw-r--r-- 1 root staff 434027 Oct 19 18:01 ./trellis/trellis_swig0.py
-rw-r--r-- 1 root staff 408950 Oct 19 18:00 ./blocks/blocks_swig0.py
-rw-r--r-- 1 root staff 387471 Oct 19 18:01 ./qtgui/qtgui_swig.py
-rw-r--r-- 1 root staff 378341 Oct 19 18:01 ./digital/digital_swig1.py
-rw-r--r-- 1 root staff 311540 Oct 19 18:01 ./digital/digital_swig2.py
-rw-r--r-- 1 root staff 241609 Oct 19 18:03 ./gr/runtime_swig.py
-rw-r--r-- 1 root staff 240924 Oct 19 18:00 ./fec/fec_swig.py
-rw-r--r-- 1 root staff 228385 Oct 19 18:01 ./vocoder/vocoder_swig.py
-rw-r--r-- 1 root staff 220498 Oct 19 18:01 ./atsc/atsc_swig.py
-rw-r--r-- 1 root staff 173558 Jun 5 2017 ./filter/icons_rc.py
-rw-r--r-- 1 root staff 162993 Oct 19 18:01 ./zeromq/zeromq_swig.py
...

[MikhailArkhipov]

Yes, I believe jedi builds ASTs for complete files so chain loading large Python files will consume a lot of memory. Would be interesting to try this in Python tools for VS...

I have a prototype solution where we monitor size of the jedi process and exit if predefined limit is exceeded. Completion code then restarts the process upon the next request. Memory threshold can be a setting. This keeps general completion alive but fails completion for complex objects.

[MikhailArkhipov]

Please see comments in the PR #744

[tzachshabtay]

@MikhailArkhipov correct me if I'm wrong, but it doesn't look like a fix, just a patch which is good to have but doesn't actually resolve the memory inefficiency (understatement of the year here), so I don't think it's fair closing this issue.

As for the patch, does it give up restarting completion.py after a few retries? Otherwise I'm hesitant to reinstall the extension so it wouldn't get into an endless process restart loop.

[elliott-beach]

As for the patch, does it give up restarting completion after a few retries? Otherwise I'm hesitant to reinstall the extension so it wouldn't get into an endless process restart loop.

I think this is handled by waiting 2 seconds before restarting the process, which is slow enough it wouldn't be a performance problem (I think???). It could repeatedly consume 1GB of RAM (the default maximum).

The change does kill auto completion for tensorflow when I tested, as the process dies before completions can be suggested.

[MikhailArkhipov]

It measures footprint every 2 seconds. The process is restarted immediately. There is no limit on restarts. Yes, it can restart again and again if you are using large code base or library. GNU Radio, for example. But at least basic completion keeps working and machine does not crash. There is no limit on retries.

You can increase limit in settings, default is 1GB, max 8GB.

@elliott-beach - yes, you may lose suggestions on certain elements - those that cause Jedi to consume RAM in a runaway manner.

@tzachshabtay - yes, it is a patch/workaround. There is nothing else we can do with Jedi memory consumption (apart from switching away from Jedi). There are several bugs filed in Jedi github from other projects on the issue. Our goal here is to keep product (and OS) functioning at least at the basic level.

[MikhailArkhipov]

See also

autocomplete-python/autocomplete-python#233
davidhalter/jedi#805
DamnWidget/anaconda#638

[zsquareplusc]

Looks like the "fix" for this (#744) is launching an external process every 5 seconds to check the completion process size: wmic process <pid> get workingsetsize,usermodetime,kernelmodetime . This in turn seems to increase the CPU load caused by WmiPrvSE.exe. Anyway the result is increased CPU load (a few percent on a core i7) with VSCode+python extension is open with a Python file.

Is there an option to disable these checks (i only see the python.jediMemoryLimit to change the limit, not the frequency)? It helps draining the battery and i personally don't like it when a process is started every few seconds, for every VSCode instance running...

[DonJayamanne]

@zsquareplusc Please could you create a separate issue for what you're experiencing.