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

Crazy high memory and cpu usage, then crash #1113

Closed
WillEhrendreich opened this issue May 11, 2023 · 2 comments
Closed

Crazy high memory and cpu usage, then crash #1113

WillEhrendreich opened this issue May 11, 2023 · 2 comments

Comments

@WillEhrendreich
Copy link

image

I'm getting a lot of typechecking updates from the lsp being sent.. like every few seconds i get a notification about it.

TypeCheckMadness

after a little bit of this, sometimes ten mins, nvim just crashes. fsautocomplete process keeps running, keeps hogging up memory, then i have to go kill the process.

any ideas??

@TheAngryByrd
Copy link
Member

👋 sorry about not answering sooner. Here's a couple things to look at

  • 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 #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.
  • 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.

@WillEhrendreich
Copy link
Author

I'm just going to close this, I'm not seeing it anymore, so I'm not sure why it was happening or why it went away, so.. ¯_(ツ)_/¯

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

2 participants