0

We have .net core 3.0 web application, hosted on Azure App services. We faced a problem when memory utilization gets the upper bound of App plan.

Is it a good idea to create a job in BackgroundService which will monitor resource usage and force Garbage Collection when memory utilization gets 80-90% of total memory usage?

Yaroslav Bres
  • 1,029
  • 1
  • 9
  • 20
  • 1
    Maybe better find reasons of memory leaks at your app? – Sergey Nazarov Oct 05 '20 at 13:04
  • 1
    The short answer is "no, it is not a good idea". The longer answer - profile the code. There are times when explicit calls to `GC.Collect` are a good idea, but they are relatively rare. – mjwills Oct 05 '20 at 13:08
  • 3
    It is never\* a good idea to do manual garbage collection in a managed runtime. \*Unless you know *exactly* what you're doing and why you're doing it, at which point you wouldn't need to ask this question – MindSwipe Oct 05 '20 at 13:08
  • The only thing I can recommend is to [profile your code](https://learn.microsoft.com/en-us/visualstudio/profiling/profiling-feature-tour?view=vs-2019), see which parts are using exorbitant amounts of memory and try to improve that code to use less. If that doesn't work there's really isn't any other option other than paying for a App plan with more memory – MindSwipe Oct 05 '20 at 13:11
  • The best way is to dispose you objects (or put in a using block) to make sure GC runs. – jdweng Oct 05 '20 at 13:17
  • 1
    I didn't find explicit memory leaks profiling the code and we are trying to use best practices (using blocks, transient lifetime objects, ect). Most likely our system is overloaded and the best option is just to increase the memory plan. My suggestion was to cheat somehow and I wondered if it possible with explicit GC call. Also, I've just read that clr runs GC when the system has a low memory level so my idea is really useless. Thanks, everyone for the help – Yaroslav Bres Oct 05 '20 at 13:28
  • GC calls are not free. Stop being cheap and just give your app the resources it needs. – Ian Kemp Oct 05 '20 at 14:32
  • @ЯрославВиталиевич Do you have many objects on the Large Object Heap? https://stackoverflow.com/a/8953503/34092 – mjwills Oct 05 '20 at 20:30
  • @jdweng I suspect your misunderstanding here is a common one, so please don't take offence at my earlier questions. `Dispose` and GC are completely different things. Calling `Dispose` does not ensure that GC runs. `So using reverse logic if you do not suppress then the garbage collection is run.` That is not correct. `GC.SuppressFinalise` does not suppress GC. It suppresses a specific _behaviour_ of GC. https://stackoverflow.com/questions/2344240/what-is-relation-between-gc-finalize-and-dispose may be a good starting point for you. Calling `Dispose` is good - it just doesn't cause GC. – mjwills Oct 06 '20 at 10:02
  • Here is a better link : https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose – jdweng Oct 06 '20 at 10:05
  • @jdweng I understand what GC and Dispose do. To be clear - I am suggesting your understanding is wrong. And it is misleading to share your current understanding with others. None of the links you have provided back up the false statement that `The best way is to dispose you objects (or put in a using block) to make sure GC runs.`. **Dispose does not make GC run** (https://ericlippert.com/2015/05/18/when-everything-you-know-is-wrong-part-one/). `Dispose` is good - but it doesn't make GC run. – mjwills Oct 06 '20 at 10:08
  • If you dispose then you don't have to worry about the GC because the object is removed. But when you remove an object GC has to run since the links have to be broken which is part of GC. – jdweng Oct 06 '20 at 10:12
  • @jdweng I wish you all the best. All I can suggest is to read the links I provided, as well as those from http://joeduffyblog.com/2005/04/08/dg-update-dispose-finalization-and-resource-management/ and Chris Brumme's earlier stuff. – mjwills Oct 06 '20 at 10:13

0 Answers0