Beta: Microsoft.CodeAnalysis.LanguageServer seems to leak.

[StringEpsilon]

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 1245 .cs files and 810 1344 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.

Edit2: See #5733 (comment) for current reproduction.

If you experience high baseline memory

Try setting "Dotnet › Background Analysis: Analyzer Diagnostics Scope" and "Dotnet › Background Analysis: Compiler Diagnostics Scope" to openFiles.

You can also try setting "Max Project File Count For Diagnostic Analysis" to a lower non-zero value. The default is 1000 - I have set it to 250.

{
    "csharp.maxProjectFileCountForDiagnosticAnalysis": 250,
    "dotnet.backgroundAnalysis.compilerDiagnosticsScope": "openFiles",
    "dotnet.backgroundAnalysis.analyzerDiagnosticsScope": "openFiles",
}

---

See also this comment for further context, if you suspect you may have a leak: #5733 (comment)

[StringEpsilon]

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

0. Open VS Code on any C# project.
1. Open any C# file.
2. Make any change to the file.
3. Save the file.
4. 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.

[StringEpsilon]

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]

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]

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]

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

[PolarisNation]

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.

[sebnor]

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:

[nellekocabrera]

Hello

[haras-unicorn]

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]

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]

I am seeing high memory consumption. Opening two instances of VSCode becomes very difficult.

[StringEpsilon]

@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]

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]

@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]

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]

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]

@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

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

[jrmegatron]

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

[dibarbet]

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

Got it downloaded - thanks!

[ytimenkov]

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

[MihaPro-CarX]

CodeAnalysis is matched by memory consumption to a large Unity project with a huge amount of content.

[Novack]

Also noting that it goes up with each action (opening file, opening side bar...), but mem is not freed on closing the files. Working on a Unity project as well.

[devil304]

Same here, 33 CSProj and it's taking over 17GB of RAM, 4GB on start

[StringEpsilon]

It looks like having the options "Dotnet › Background Analysis: Analyzer Diagnostics Scope" and "Dotnet › Background Analysis: Compiler Diagnostics Scope" set to fullSolution increases baseline memory utilization by a lot.

With fullSolution the setting Max Project File Count For Diagnostic Analysis also affected the behavior.

Test procedure:

1. Set both Scopes to fullSolution / openFiles respectively
2. Close and re-open VS Code.
3. Wait for CPU load to go down (indicating that the LSP is done analyzing).

Scopes	max file count	memory
fullSolution	250	5.8 gb
openFiles	250	2.0 gb
fullSolution	0 (unlimited)	no steady state was reached after 10 minutes, test aborted
openFiles	0 (unlimited)	2.0 gb

Tested solution size:

• 1 Solution
• 2 projects
• 1300 c# source files.

This might help some people with excessive memory utilization on big solutions.

I have not tested the impact of the respective setting on the observed memory leak. Only idle memory directly after reaching steady state. Tested with the extension version v2.22.5.

[wasakidog]

I was having problems with memory usage on the language server, but after reading this issue I was able to solve the problem for the last time.

1. Open the configuration (CTRL+,)
2. Type "dotnet" in the search box
3. Select Text Editor
4. Set Dotnet > Background Analysis Analyzer Diagnostics Scope to none

Hope this helps some of you.

[arunchndr]

Would be good to test repro after release of dotnet/roslyn#73201

[StringEpsilon]

Would be good to test repro after release of dotnet/roslyn#73201

In v2.28.8 (pre-release) I can no longer force a leak via the "format document" spam method explained here: #5733 (comment).

Total memory utilization when idle (and after reaching steady state w/ regards to solution analysis) also is lower. Before it was ~3gb, now it is ~2.1gb. I'll have to do more thorough testing, but I think this might be a fix as for the memory leaking. Unworkably high baseline memory use should probably be continue to be tracked in a separate issue.

[japasc]

Repro here.

Version latest pre release as of 2024-05-01
Fedora 40 Intel x64

1. Create a new project (dotnet new console)
2. Copy and paste 100 times the generated Console.WriteLine("Hello, World!");
3. Use the arrow keys to move between those lines up an down

Result here, monotone increase in memory usage

[StringEpsilon]

I can partially confirm that reproduction. It generally works, but I can not increase the memory footporint of the language server process beyond 1374mb with that method. And if I then do other stuff on the file that increases memory (such as removing some lines, adding the lines back, formatting the file, etc.) it then goes back down sometimes.

Not sure if this is a leak per se or just some caches not being evicted and the memory space for those caches being rather big.

[arunchndr]

@CyrusNajmabadi this discussion might pique your interest.

[mikejurka]

For our project we easily see 10GB+ of memory usage right away, and sometimes rising to 20GB+

[idvhfd]

And here I was hoping I'd scroll down to a solution, only to be met with complaints as recent as today. At least I know that my solution running me at a baseline 2.4gb RAM and expanding to infinity is common.

I find that, as inconvenient as it is, changing the scope to open files or reducing the max files for diagnostics tool in the settings as per the OP's suggestion is the only way to not choke my workstation.

Since it's ongoing I'll try to investigate further, maybe there is something we can do on our end.

[doganince]

Hi there, I spend 3 days for this issues, probabyly i tried all advice for this issue but no result. Is there any planed solution for c# dev kit, i dont wanna swicth to Rider.

@mavasani

[VitaliyMubarakov]

Hi there, I spend 3 days for this issues, probabyly i tried all advice for this issue but no result. Is there any planed solution for c# dev kit, i dont wanna swicth to Rider.

@mavasani

The only solution is Visual Studio.

[doganince]

Hi there, I spend 3 days for this issues, probabyly i tried all advice for this issue but no result. Is there any planed solution for c# dev kit, i dont wanna swicth to Rider.

@mavasani

i installed latest update but same status
c# ext version: v2.34.12
dev kit ext version: v1.7.27

[MihaPro-CarX]

Even more insane memory consumption v2.39.28 (pre-release)

[MihaPro-CarX]

And it seems that after VSCode is closed, dotnet processes leak and remain forever in memory with the missing parent process

[celikomerdev]

Even more insane memory consumption v2.39.28 (pre-release)

Actually my memory issue seems solved but define symbols are not working correctly, it seems all define symbols are disabled.
C# v2.39.28 (pre-release)
C# Dev Kit v1.8.14
.NET Install Tool v2.1.1
Unity v1.0.2
default settings for csharp, omnisharp, dotnet

[StringEpsilon]

Update on the reproductions: #5733 (comment) - those still work as I described, but the overall memory use is down. 900mb instead of 1.3gb.

I thought I found a new way to make the language server leak properly, but it "only" goes to 3.1gb before it becomes stable:

1. Copy and paste 5 to 10 thousand lines of "Hello World".
2. Change one of the lines so it stands out a little.
3. Use VS Codes "move line down" hotkey to move that line down about ~1k positions. I put something on my keyboard and grabbed a coffee.

This is also really heavy on the CPU. I had all my cores at 80% load during that.

---

@MihaPro-CarX I think your symptoms deserve a separate issue. I have never seen elevated memeory on the ServiceHost.exe. Only the language server (Microsoft.CodeAnalysis.LanguageServer). The orphaned dotnet.exe processes are also something for another issue, I think. For reference when I open a barebones C# project, I have 2 dotnet processes. Tho it might be that I don't see any orphans because I'm on linux. Either way this is strange behavior outside the scope of this issue or even "memory leak" in general.

[MihaPro-CarX]

For reference, I would like to add that we have a very large Unity project; solution includes 301 projects.

[a-usr]

For me the Language Server tends to just eat all of my avaiable memory before crashing because it cant take any more. Im talking about a whopping 55 Gigabytes here.

[StringEpsilon]

With the preview release 2.41.26 (https://github.com/dotnet/vscode-csharp/releases/tag/v2.41.26) I can no longer provoke any apparent "leak" when disabling the newly added dotnet.server.useServerGC option. See #7155

Important to keep in mind that disabling server GC may hurt performance of the language server.

I think that what I observed past my initial report with the rapid heap growth to 13 gigabytes was just the server garbage collector doing what it was designed to do. Unbearable baseline heap use as reported many many times in this issue notwithstanding, but that's a different category of bug.

[dibarbet]

I think that what I observed past my initial report with the rapid heap growth to 13 gigabytes was just the server garbage collector doing what it was designed to do. Unbearable baseline heap use as reported many many times in this issue notwithstanding, but that's a different category of bug.

Yup - server GC is generally less aggressive at collecting back memory, so you can often see memory usage grow as long as you have available memory.

We're also suspicious that there may be an issue where serverGC isn't appropriately releasing memory even under higher pressure.
Would be useful to know if anyone experiencing slowness or crashes related to high language server memory usage sees improvement when turning off serverGC (uncheck dotnet.server.useServerGC and reload the window). If you still see what appear to be leaks with serverGC off, please send memory dumps (my MSFT email is in my profile, reference this issue #).

As for the relatively high baseline memory usage, we are always working on reducing memory usage (some of the changes can be seen in the changelog). However I wouldn't expect huge drops here, until we add features such as #6008 (to avoid needing to represent the entire solution at once in memory)

[celikomerdev]

I don't know if it's a solution or not, but i discovered i can work fine with unity by adding "dotnet.preferCSharpExtension": true to workspace settings.json, now my memory went from +10gb to 2-3gb and all define symbols are working fine too.
C# v2.39.29
C# Dev Kit v1.8.14
Unity v1.0.2