-
Notifications
You must be signed in to change notification settings - Fork 133
high Memory Usage (again) #2007
Comments
There should not be that many instances unless you have multiroot workspace with that many roots. |
The screenshot is from htop with threads shown (green lines); the above are threads of the same process. |
Yes, I should have mentioned that. There is only one process but with many threads (which I am not worried about). It's about 12G virtual and over 5G resident. It could be just that it is traversing many python librariers. But the way I use vscode this will always happen if it goes deep enough into my library. I'm guessing it is building some kind of index on the fly without spilling anything to disk? I'm not quit clear on what it would be holding in memory that is beyond what a normal IPython session would hold (which I also run important much of the same code). |
You used the question form; our bug form asks for a bunch more info that we'd need to figure out anything about what's going on. I suggest providing that info, which is mirrored here: https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#filing-an-issue |
Still a bit odd there are that many threads unless analysis is still in progress and even then it should be limited to number of CPUs. |
As far as I know, this has sorta been the case for a while. For example, see the screenshot in #1755. IIRC we only limit the number of tasks, and to a multiple of the CPU count, but I don't think we're directly limiting the thread count anywhere unless I've missed something. |
The screens in that issue are from an issue I currently have with a couple of files that seems related to a circular import going on between the 2 of them. If I open other project or other files in the same project the LS never goes extremely high in memory usage or thread count, but opening these files, there are 3 of them haven't been able to determine if is a combination of them or simply one of them, makes my memory go high, thread count to spike, LS to become not responsive and sticks around after I close the VSCode client until I forcefully kill it. |
Right; I was just referring to the |
From the issue screenshot and what I see on my end it could def be related. But that's just a theory. |
#1460 ? |
Memory leak.
System: Windows10 2004 Version: 1.46.0-insider (user setup) |
I have similar experience. Definitely some kind of leak. Leaving an VS Code session open, but untouched over night or after some days can cause the whole computer to become unresponsive. Running on Mac OS No problem with fresh VS Code session, but deteriorates over time. Have verified multiple occasions that |
Try
see of 0.5.51 is any better. |
I've been using the daily channel for some time. 0.5.51 doesn't seems to have any positive impact on the issue for me. |
I would consider trying out our new LS, Pylance, to see if its performance characteristics work better for you. |
5.51 isnt any better. running on Ubuntu 18.04.3 LTS its eating my entire virtual memory space in under an hour ( 36gb ) it sits on "analyzing in background" how do i disable? |
You can try |
ty, works as expected |
Is this high memory usage expected? Is vscode collecting informatino about this? I feel like I've filled out quite a few feedback surveys. Is there something to switch to for python? Main thing we need is click through to definition.
The text was updated successfully, but these errors were encountered: