2

Ok, so I have an app with pretty heavy traffic (about 17 requests per second). The app is a REST API built with .Net Core 2.0 (just recently upgraded).

The app is hosted on Azure and we are having a problem that looked like a memory leak in that the servers would very slowly (over a week) eat up all the handlers and resources and eventually crash.

I have spoken a good bit to MS Support and they helped me narrow down the problem. Here is their last email:

"We are seeing a high amount of large objects (strings and arrays over 85000 bytes) can lead to GC Heap fragmentation and thus higher memory usage in your application. We were investigating how to manage the destructor and I can provide you the following documentation:

I will continue looking for more documentation related with the destructor in .NET Core."

After this they basically said that Azure was not to blame and I needed to open up a "code" support ticket that costs about $500...

So I am coming here instead. :)

While I have been a .Net developer for over 15 years, this was my first time using .Net Core. I found this great article and used it as the backbone to my API (https://chsakell.com/2016/06/23/rest-apis-using-asp-net-core-and-entity-framework-core/).

When I compared it to other .Net Core examples it seemed to fall in line with those so I am reasonably confident that I am following "best practices", but I could be wrong.

My fear is that there is a fundamental problem with .Net Core (which those articles that MS referred to kinda suggest), but I am not sure how to find the answer. I don't want have to rewrite my code because of this, but aside from occasionally rebooting the servers I am not sure what my options are.

Thoughts?

David
  • 2,173
  • 3
  • 25
  • 36
  • It seems that the root problem is not really due to the Finalizers but to your program relying too much on the Large Object Heap (which causes memory fragmentation and expensive compaction process). So the first question you need to answer is where those allocations are coming from. – Cyprien Autexier Sep 08 '17 at 04:54
  • 1
    I would start with the creating / downloading a dump from Kudu : https://blogs.msdn.microsoft.com/jpsanders/2017/02/02/how-to-get-a-full-memory-dump-in-azure-app-services/ and then opening it with visual studio and "Debug Managed Memory" – Cyprien Autexier Sep 08 '17 at 06:01
  • 1
    Hard to say, we don't know your code. Are you correctly implementing IDisposable pattern for your services which need managed memory? – Tseng Sep 08 '17 at 06:10

1 Answers1

0

Ok... for posterity... my eventual solution turned out to be a configuration setup issue... the destructor issue with Core wasn't a factor for me because we weren't sending strings large enough to trigger it.

You can see my approach and the eventual answer (using a singleton) in this question:

ASP.Net Core 2 configuration taking up a lot of memory. How do I get config information differently?

David
  • 2,173
  • 3
  • 25
  • 36