Open StringEpsilon opened 1 year ago
For reference, I would like to add that we have a very large Unity project; solution includes 301 projects.
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.
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 https://github.com/dotnet/vscode-csharp/pull/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.
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 https://github.com/dotnet/vscode-csharp/issues/6008 (to avoid needing to represent the entire solution at once in memory)
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
Environment data
dotnet --info
output:VS Code version:
1.78.2
C# Extension version:v2.0.206
OmniSharp log
Not applicable.
Steps to reproduce
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
7471245 .cs files and8101344 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 to250
.See also this comment for further context, if you suspect you may have a leak: https://github.com/dotnet/vscode-csharp/issues/5733#issuecomment-2261386528