Azure Cloud Service issue with web role (web application) memory issue (Gen2)

Question

I have a question regarding the use of high memory as a web role with an MVC application, with Simple Injector like DI, Entity Framework 6 for DAL. The application runs on the Azure Cloud Service as a web role with 2 standard A2 instances (2 cores, 3.5 GB of RAM), and CachingService (Shared Role) with 20% memory usage.

The problem is that when you start or restart the instance, using the w3wp.exe memory using only about 500-600 MB of memory (when using all other applications, about 50%), but even if there are no requests in it, it starts and continues to grow to 1 , 7 GB and ends (when using all other applications about 90%). But I noticed that the memory sometimes crashes accidentally and, of course, after a reboot or republishing.

After monitoring the heap of memory, I noticed that this is a Gen2 Heap that grows and remains large, and after debugging locally with the ANTI Memory Profiler, I saw that the largest number of Gen2 was taken by Entity Framework objects with the class names “TypeUsage” and “MetadataProperty”, objects (namespace System.Data.Entity.Core.Metadata.Edm).

Now my question is:

• This is a memory leak in our code and how can I solve it if it is (I checked and already tried to remove the DbContext that each request is created)?
• Is it a memory leak in EF, if so, what can I do with it, maybe another DAL structure?
• Is this normal behavior and should I leave it as it is?

Answer 1

There is a very low probability that this is a memory leak in EF, and this is not normal, and you should not leave it like that. Your memory leak code.

The best way to find a leak is to use a memory profiler (ANTS is a good option, I used dotMemory). The profiler will show you leaked objects, and it should also show you two more important things:

• Trace the location stack in the code where the object was created.
• An object tree that refers to your leaked object and does not allow it to be collected.

They should help you understand how objects were created and why they were not GC'ed.

You mentioned that most of the memory is in Gen2. This means that your leaked objects are referenced by something "for a long time." It could be a static variable, an ASP.Net application, or something like that.

An accidental memory drop may occur when IIS is processing your application. By default, this happens every 29 hours, but IIS may be configured differently or may decide to rework your application for some other purpose.

Answer 2

"But I noticed that memory sometimes falls by accident ..."

This is probably not a memory leak, but a problem of uncontrolled growth in garbage collection. I came across something similar a few years ago.

The problem is that, by default, the garbage collector allows the process memory to grow until its size closes some of the limitations of fully available memory in the OS. When your process starts in a cloud environment, which is a kind of shared hosting, it is possible that it still does not reach the necessary memory associated with the OS point of view, and therefore memory is not collected, but it limits the memory limit for the general process.

I would recommend that you force the garbage collector to collect the memory carefully using GC.Collect(0); periodically, after a certain number of operations. Maybe this can solve the problem.

Answer 3

I had a similar problem (a web application with EF and a lot of TypeUsage taking up memory in a dump) and found that the Enable 32-bit applications option in the application pool significantly reduced memory usage.