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 https://github.com/dotnet/vscode-csharp/issues/5733#issuecomment-1665550830 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 https://github.com/dotnet/vscode-csharp/issues/5733#issuecomment-1938428637 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",
}

[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 (https://github.com/dotnet/vscode-csharp/issues/5733#issuecomment-1582412297) 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).

[Mupli]

any news on this ??? Especially the cpu performance hit when writing the code.

[lfd547]

I get this, continuously high cpu usage

[SuperMB]

Just to add to the voices, the language servers are continuing to eat GBs of my RAM, even if hardly anything is open or any changes being made.

[StringEpsilon]

@SuperMB

I believe the elevated baseline memory should get it's own separate issue. I just so happen to be in the middle of refactoring a bunch of stuff and I have not seen the memory utilization increase nor does closing and reopening reduce the memory occupied by the language server.

For a comparison: I have a solution with a single project and 2500 .cs / .cshtml files. Usually the language server sits just shy of 3GB for me. If I just open the project without reading or modifying any files it's about 500 MB. Working on the project then rapidly increases the memory to about 2.9 gigs. But it never exceeds that anymore regardless of how long I work on the project or how many changes I make. I've even had VS Code open continuously for a full weekend once (whilst intermittently working on the code) without any growing memory issues.

By the looks at the comments most people just have really high - sometimes unusable high - baseline memory utilization. From what I can tell the number of projects is the biggest factor. But even on that I am not entirely sure. Can you give more details about the scenarios where you see unacceptable levels of RAM use? Number of files, number of projects, number of nuget packages, etc.? Does it actually leak or does it reach a steady state? Can you cross-compare those with other solutions of yours?

FYI The only reason I have not closed this issue is that I can not say if it's just fixed for me and oddball singular giant project or if it's fixed for everyone.

[SuperMB]

Yes, I'll try to get some numbers together soon. I've been paying attention to usage based on number of projects etc. after your comment. I'll try to actually put something quantitative together.

[QuipHop]

Got Same :( Running not really big Unity project with not so many additional packages.

[MihaPro-CarX]

I have 147 projects in Solution (Unity big project)

[StringEpsilon]

I have found a new way to reproduce a proper memory leak:

Formatting a source document ever so slightly increases the total memory for the LSP process, even if the formatting has absolutely no effect on the document. The effect stops after a while, but can be continued simply by opening another file, making a change, saving the file and then holding down the format document shortcut.

This way I managed to increase my LSP memory from ~700mb to 3 gigabytes in a matter of minutes and unlike with normal use (opening files, editing files, saving files) the memory does not go back down.

I do not have format-on-save enabled (due to a buggy interaction with *.cshtml files) but I believe that if one has that on this might contribute somewhat significantly to the elevated memory usages people continue to report.

Version: v2.17.7 (pre-release)

[VitaliyMubarakov]

Microsoft.CodeAnalysis.LanguageServer — RAM usage increases exponentially from 300 mb to ∞

[hosamre94]

Same here, Microsoft.CodeAnalysis.LanguageServer is consuming 90% of that without a single file open, and for every c# file I open it just goes up another 300~MB

[herrbpl]

I had cases where it repored 250G mem usage (by top on remote ssh workstation). This extension is just crazy. Uninstalled it all.

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

[arkalyanms]

Would be good to test repro after release of https://github.com/dotnet/roslyn/pull/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: https://github.com/dotnet/vscode-csharp/issues/5733#issuecomment-1938428637.

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.

[arkalyanms]

@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: https://github.com/dotnet/vscode-csharp/issues/5733#issuecomment-2089736763 - 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.