Memory leak when running project

[PaigeM89]

Describe the bug

When running Ionide on my main work solution, it works fine up until I run the project(s). When I do, Ionide will continue to work but will continually use up more and more RAM until I'm forced to kill the service - just now, it was sitting on 18 gigs of ram & slowing my machine to a crawl. I can consistently recreate this - or, more accurately, every time I run the projects, I get a memory leak.

I'm the only person on my team with this issue at all, and it only happens for one solution. However, this is a pretty big solution - 32 individual projects. I haven't had this issue across any other solutions, just this one. It might be worth noting that it appears that Ionide uses up a fair amount of memory even when running fine - without the issue currently happening, it's sitting on 2.8 gigs of RAM.

Steps to reproduce

1. Open up my main work solution on my laptop
2. Launch it from the terminal via tye
3. Watch ram usage skyrocket

Machine info

• OS: Mac 12.2.1, has happened for a few versions
• .NET SDK version: Has happened for a few versions now, currently happens on 5.0.404
• Ionide version: Has happened for a few versions now, currently happens on 7.0.0

Additional context

We use tye for running our containers & orchestrating our services, but I'm able to get a memory leak when running the services "normally".

Let me know what I can provide to debug this. I took a memory dump, but it's 11 gigs and I can't open it on my OS (so I don't even know if it's working).

[PaigeM89]

I can even get this to happen without any processes running, which is interesting & uncommon.

[aonyxrocks]

Same issue here. But the project I am working on is very small. Just an Azure function and a Pulumi project. This seems to be triggered just by editing code and/or displaying intellisense. The point where it got in the way of getting any development done was when working on some nested CEs (Pulumi.FSharp.AzureNative).
I downgraded to v6 which does not behave as badly (CPU/memory consumption is still an issue but nowhere near as bad).

• Windows 10
• .NET SDK 6.0.302
• Libraries used in the projects:
  • Azure.Identity
  • Azure.ResourceManager
  • Azure.ResourceManager.Resources
  • Azure.Security.KeyVault.Secrets
  • Farmer
  • FsToolkit.ErrorHandling
  • Pulumi
  • Pulumi.AzureNative
  • Pulumi.FSharp
  • Pulumi.FSharp.AzureNative
  • Pulumi.FSharp.Core

Edit: It looks like even v6 has this problem but is much slower to consume the resources, so it is not as noticable.

[sebfia]

Same issue here.
Machine: MBP ARM64

[jormal]

Same issue here.
Machine: Mac mini (M1, 2020) ARM64
OS: macOS 12.4

Also, when I downgraded the Ionide to 6.0.6, this situation doesn't occur.

[wallymathieu]

I'm getting a spike in the CPU usage on Air M1 8GB when I open up
https://github.com/wallymathieu/auctions-site
I'm using .net version 6.0.302

[wallymathieu]

It's fine when I'm using Rider or Visual Studio for Mac though.

[sleepyfran]

Same as @wallymathieu on my M1, after opening a file dotnet CPU's usage skyrockets and stays until I kill VSCode:

Not sure if there's a way to report any performance logs, if so I can attach them since it happens continously.

[sebfia]

Switching back to v 6.x solved the problem for me imho

…

Am 09.08.2022 um 01:46 schrieb Fran González ***@***.***>:  Same as @wallymathieu on my M1, after opening a file dotnet CPU's usage skyrockets and stays until I kill VSCode: Not sure if there's a way to report any performance logs, if so I can attach them since it happens continously. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[forki]

same here. Switching back to 6.0.6 solves it.

[draganjovanovic1]

Confirming high CPU usage on M1 Max with ionide 7.0.0. (all performance cores and fans to the max, melting aluminum :) ). Tried to let it for an hour hoping it will do it's work and calm down but didn't happen. Reverted to 6.0.6 and working again in quiet :)

[baronfel]

This is probably due to a lot of rework that we are doing during checking. @Krzysztof-Cieslak has a draft PR to correct some of that that we are working through.

[kevingentile]

Can confirm this issue in v7.0.0 ( In v7.1.0 I was mostly impacted by #1769 ):

• Windows 10
• .NET SDK 6.0.303

Rollback to 6.0.6 seems to resolve issues.

Workaround is a manual restart of extension host in VSCode. But this pops up frequently enough that it's probably best to roll-back. Is there an easy way to trigger a restart of the Ionide extension only?

[baronfel]

@kevingentile there is not. This was solved in 7.1.0, and #1769 should be resolved in the next version, so really all I can advise you to do is hold tight.

[baronfel]

Closing because 7.1.0 solved this particular issue.

[wallymathieu]

It's still not working on 7.1 for macos

[TheAngryByrd]

Can you try with the AdaptiveLSPServer?

[wallymathieu]

M1, Ionide v7.4.2, .net 7.0.200. CPU is stable. I've tried both with FSharp: Enable Adaptive Lsp Server enabled and not. For the project auctions-site it seems like the CPU issue is fixed.

[wallymathieu]

.net is around 1.6 GB after maybe 30 minutes.

[cartermp]

FWIW I think 1.6GB of memory usage on 64-bit out-of-proc for a project using FSharpPlus isn't too out of the ordinary.

[wallymathieu]

It's now 1.8 GB.

[TheAngryByrd]

You may want to use some type of memory dump to analyze what is taking up memory. When I did it for my giant work project, it takes quite a bit of memory but it's almost entirely inside FSharp.Compiler.Service which we don't have much control over (please let me know if there's better memory controls).

Additionally try setting DOTNET_GCConserveMemory=9 environment variable before starting vscode as I've noticed this will help the GC be more aggressive at cleaning up Large Object Heap allocations in FSharp.Compiler.Service.

[wallymathieu]

I mean, there might be some memory leak. For my part the biggest issue is solved (that you couldn't use it at all due to high CPU).

[TheAngryByrd]

Ok I've done a lot of memory performance tuning over the months.

• If you're on macOS, ARM processor, and dotnet 6, you're out of luck. This is an issue in the runtime and there's not much we can do.
• If you have a type provider, there was some bug in how we were using FCS Type Provider leaking memory in FSAC dotnet/fsharp#15014 but that seems resolved with one of the later versions.
• For bigger projects there are some recommended settings. The conserve memory configuration lets the runtime compact more often and even compacts the Large Object Heap which is often a cause of issues because of large source files
• I also recently implemented RoslynSource Text FsAutoComplete#1123 which you can add the switch --source-text-factory=RoslynSourceText to enable. This should have less Large Object Heap hits.
• We do use the Server GC by default which is pretty aggressive at allocating memory. If it still seems like an issue you can play with certain environment variables like Heap count so you don't have as many heaps but still get some benefits of Server GC. Otherwise you can turn it off and use workstation but know that will come with some significant performance hits since FCS and by proxy FSAC are garbage collector intensive. I recently added the ability to change these settings directly rather than through some environment variables.
• Lastly using dotnet-dump then using PerfView or DotMemory. The analysis can be quite a rabbit hole but you should be able to get some indication of what's eating up memory.