Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beta: Microsoft.CodeAnalysis.LanguageServer seems to leak. #5733

Open
StringEpsilon opened this issue Jun 8, 2023 · 20 comments
Open

Beta: Microsoft.CodeAnalysis.LanguageServer seems to leak. #5733

StringEpsilon opened this issue Jun 8, 2023 · 20 comments
Assignees
Milestone

Comments

@StringEpsilon
Copy link

StringEpsilon commented Jun 8, 2023

Environment data

dotnet --info output:

.NET SDK:
 Version:   7.0.100
 Commit:    e12b7af219

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.100\

VS Code version: 1.78.2
C# Extension version: v2.0.206

OmniSharp log

Not applicable.

Steps to reproduce

  1. Open a medium sized .NET project.
  2. Work on the project for a while.

Expected behavior

The LSP just works.

Actual behavior

Right out of the gate, the process "Microsoft.CodeAnalysis.LanguageServer" is utilizing about 1 to 1.5 GB of ram after the initial scan of the solution is complete. After navigating through the solution a bit, as one would for a bugfix or a small feature, the memory utilization jumps to 3-4 GB.

From there, memory utilization slowly creeps up as one continues to work on the solution. My "record" so far is 9.8 GB of utilized ram. I do have a lot of RAM, and I have it so I can use it. But this creeping up in utilization is a bit concerning and suggests to me that that there is a leak.

For context, the solution consists of 747 .cs files and 810 cshtml files.

Edit: As per my comment here #5733 (comment) I can no longer say that the LSP leaks per say. But many people still report elevated memory utilization. For me personally the issue is resolved.

@StringEpsilon
Copy link
Author

I just found a very easy way to provoke the leaky behavior:

  1. Open VS Code on any C# project.
  2. Open any C# file.
  3. Make any change to the file.
  4. Save the file.
  5. Repeat steps 2 and 3 about 100 times.

That pushes memory utilization to about 4 gb reliably for my project in a matter of seconds.

Testing with other solutions I have, the rate of memory increase seems to correlate with the overall solution size. A small-ish library I have with 93 files I struggle to get over 1.4GB, even with this method. But it does leak nonetheless.

@dibarbet dibarbet added this to the GA milestone Jun 8, 2023
@dibarbet dibarbet self-assigned this Jun 8, 2023
@StringEpsilon
Copy link
Author

StringEpsilon commented Jun 10, 2023

Some additional observations:

Memory utilization does actually go down, if you let VS Code sit long enough without interacting with it. But this is on the scale of hours, not minutes.

Performance of the LSP does not seem to degrade much.

The leaking jumps up significantly when one is reorganizing a large subsection of code. Right now I am looking at 13 GB of RAM being utilized by Microsoft.CodeAnalysis.LanguageServer. Accumulated over about 2 hours of moving files around and changing namespaces and whatnot. That is almost half of my system memory.

Edit: Since posting this update, I have left VS Code untouched. Memory usage went from 13,000mb to 12,200mb over roughly an hour.

Edit number 2: Another hour later and it sits now at 10.300mb

@derwissel
Copy link

Don't know if exactly related, but for reproduceability:

When working with C# Scripts (.csx), using dotnet-script, even toggling a comment on a single line of code in a small script will make memory consumption rise by 100MB here.

@WalissonPires
Copy link

I have a solution with about 100 projects. I've been working on it with VSCode and C# Language Extension (v1.25.9) for a few years and haven't had any problems. But after installing the C# Dev Tools extension (which updated the C# Language extension to beta) I started having the same problem of Microsoft.CodeAnalysis.LanguageServer consuming a lot of RAM (In my case 6GB+ out of 12GB) and never releasing it.

Just the fact that I open vscode with 5 code tabs open, without touching anything, already increases the amount of RAM.

@Igorgro
Copy link

Igorgro commented Jun 19, 2023

I also noticed that new LSP Host cause high CPU usage when typing something:
image

@PolarisNation
Copy link

I feel the same.
After using C# Extension as vscode for a year, after the C# Extension update, it already occupies more than 4.5 gigabytes of memory, even though it doesn't debug or do anything.
If I try to work, the speed is already slow and even disconnects.
I would like to ask if I can use the previous version other than the recent update.

@arkalyanms arkalyanms modified the milestones: GA, Post GA Jul 25, 2023
@sebnor
Copy link

sebnor commented Aug 2, 2023

Working in a quite large project (.NET 7) and since moving from OmniSharp to DevKit the memory consumption is insane. After working with the project for a while i often reach 20Gb or more of memory usage:
image

@dibarbet dibarbet modified the milestones: Post GA, Next Aug 2, 2023
@nellekocabrera
Copy link

image
Hello

@haras-unicorn
Copy link

image
not a huge project but same
whenever i try to build some c# project outside of vs code, vs code becomse basically unusable for a minute because i cant move the cursor or insert anything and it keeps hogging up my cpu

@StringEpsilon
Copy link
Author

StringEpsilon commented Aug 4, 2023

To provide some actually useful info instead of just repeating that the issue exists (🙃):

Since opening the issue, the leak has become less severe. It still leaks and can reach some very absurd memory utilization, but in regular working on the same repository I worked on when I opened this issue, I haven't seen it go as high as it used to. And I documented in my second comment that the allocated RAM is very slowly getting released again. That slow release has improved a little.

Another thing I just noticed is that forcing the leak by rapidly making trivial edits and undoing them again and saving in between (#5733 (comment)) does not work quite as well now. I can get a couple hundred MB out of that, but it does not grow indefinitely anymore like it used to.

Will need to do more testing to see just how much things have improved. But at least the LSP is not quite strangling my machine anymore while making light edits or just reading code.

Edit: Actually I am having a hard time getting the allocated memory to go above 4GB when it was trivial to push it above 10gb before. Using version v2.0.320 of the "C#" extension and v0.4.2 of "C# Dev Kit".

To the other commenters: Have you observed actual leaking (constant growth of allocated memory over time) or just a very high base utilization of memory? I'm seeing around 2.5gb right after the solution loads and the LSP is done with the initial scan. Then it goes to around 3GB and now stays there with some bursts above while I'm working on the project.

@MihaPro-CarX
Copy link

изображение
I am seeing high memory consumption. Opening two instances of VSCode becomes very difficult.

@StringEpsilon
Copy link
Author

StringEpsilon commented Aug 7, 2023

@MihaPro-CarX Just to confirm there: Are you experiencing a memory leak or are you seeing that kind of allocation as a baseline that does not meaningfully and permanently increase as you work on the code? As per my last comment I have been unable to replicate a memory leak.

I am not saying that having that kind of memory utilization is good. But distinguishing between high baseline memory and a leak is important and I'd be curious to figure out a reliable way of replicating that again.

@dibarbet
Copy link
Member

dibarbet commented Aug 7, 2023

For anyone hitting memory, issues, if you can please send us a dump of the process. This can be collected with dotnet-dump - https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dump

The process you'll be looking for on Windows / Linux is 'Microsoft.CodeAnalysis.LanguageServer.exe' (on mac it will be a dotnet.exe process launched against the Microsoft.CodeAnalysis.LanguageServer.dll).

If you don't feel comfortable sharing publicly, my microsoft email is listed in my github profile.

Some notes

  1. A memory leak is definitely bad and something we want to fix. If you're having a memory leak send me a dump.
  2. We use servergc which can be less aggressive at collecting back available memory. There's likely some additional tuning we can do here, but in general I don't think its unexpected that the 2.x version uses more memory. If it's using too much and causing perf issues, that is definitely a problem.

@MihaPro-CarX
Copy link

@MihaPro-CarX Just to confirm there: Are you experiencing a memory leak or are you seeing that kind of allocation as a baseline that does not meaningfully and permanently increase as you work on the code? As per my last comment I have been unable to replicate a memory leak.

I am not saying that having that kind of memory utilization is good. But distinguishing between high baseline memory and a leak is important and I'd be curious to figure out a reliable way of replicating that again.

I can't say it's a memory leak. We have a very large project, the solution contains 264 csproj. When you open a solution, memory consumption reaches a certain high level and remains there. My opinion is that this is a very large memory consumption by the analyzer, which begins to block work on the workstation.

@DanOli2021
Copy link

DanOli2021 commented Aug 16, 2023

I probably have an idea of what the problem's cause might be. I have a program that runs C# scripts, or in other words, CSX files. I faced the same issue of excessive memory usage. The solution I found was elementary. When I executed the code, I used:

// This is how I had it
var script = CSharpScript.Create(code, options, typeof(Globals));
var result = script.RunAsync(g).GetAwaiter().GetResult;

// This is how I use it now
var script = CSharpScript.Create(code, options, typeof(Globals));
ScriptRunner runner = script.CreateDelegate();
var result = runner.Invoke(g);

This solved the problem for me because it seems that RunAsync loads all debugging symbols every time it's called, and therefore, it consumes a lot of memory. On the other hand, when you create a delegate, they are loaded only once.
I'm not entirely sure if this is the case; I'm just sharing a bit of my experience.
The problem lies directly within the extension, and we would need to use delegates to solve the issue.

@jrmegatron
Copy link

Hi @dibarbet ! We have a medium size workspace with .Net code (approx. 30-40 csproj files). Running VS Code on Windows 11 and Microsoft.CodeAnalysis.LanguageServer is taking 9GB+! VS Code is extremely sluggish and i often have to re-build multiple times for intellisense to work, debugging unit tests works some times and doesnt other times.

I have taken a memory dump of the Microsoft.CodeAnalysis.LanguageServer PID. How can I securely send it to you?

@dibarbet
Copy link
Member

@jrmegatron
Sounds like it'll be too large to email as an attachment - if you can would you be able to upload it to a onedrive / dropbox / etc and privately share a link to it via email? My email is dabarbet@microsoft.com (also listed in my github profile).

If that doesn't work you can create a fake VS feedback ticket if you have VS installed via Help-> Send Feedback -> Report a problem and then just attach the vscode dump to that ticket and send me the link to it
image

We're still working out a better system to share large dumps 😆

@jrmegatron
Copy link

@dibarbet I sent you an email directly with a link to download the dump file. Please confirm. Thanks.

@dibarbet
Copy link
Member

@dibarbet I sent you an email directly with a link to download the dump file. Please confirm. Thanks.

Got it downloaded - thanks!

@ytimenkov
Copy link

I experience high memory and CPU usage with Unity project (replaced old Unity extension with Microsoft's one). I can't say the project is exceptionally large (I even unchecked generating projects for packages), but after opening language server keeps working set at 6.1 Gb. (C# extension v2.1.2). My colleague said Rider fits into 4.4 Gb for the same project, but this includes whole app and all packages, not just language server.

asp.net or dotnet-runtime took much less resources (although they may be opened differently since I couldn't do restore and just used loading on demand with the previous version of extension).

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

No branches or pull requests