C# WebAPI Garbage Collection

Question

I just delivered my first C# WebAPI application to the first customer. Under normal load, performance initially is even better than I expected. Initially.

Everything worked fine until, at some point, memory was up and garbage collection started running riot (as in "It collects objects that are not yet garbage"). At that point, there were multiple W3WP threads with some ten gigs of ram altogether, and single-digit gigs per worker. After a restart of the IIS everything was back to normal, but of course the memory usage is rising again.

Please correct me if I am wrong, but

• Shouldn't C# have automatic garbage collection?
• Shouldn't it be easy for GC to collect the garbage of a WebAPI application?

And please help me out:

• How can I explicitly state what GC should collect, thus preventing memory leaks? Is someBigList = null; the way to go?
• How can I detect where the memory leaks are?

EDIT: Let me clarify some things.

My .NET WebAPI application is mostly a bunch of

public class MyApiController:ApiController
{
    [HttpGet]
    public MyObjectClass[] MyApi(string someParam) {
        List<MyObjectClass> list = new List<MyObjectClass>();
        ...
        for/while/foreach {
            MyObjectClass obj = new MyObjectClass();
            obj.firstStringAttribute = xyz;
            ...
            list.Add(obj);
        }
        return list.ToArray();
    }
}

Under such conditions, GC should be easy: after "return", all local variables should be garbage. Yet with every single call the used memory increases.

I initially thought that C# WebAPI programs behave similar to (pre-compiled) PHP: IIS calls the program, it is executed, returns the value and is then completely disposed off.

But this is not the case. For instance, I found static variables to keep their data between runs, and now I disposed of all static variables.

Because I found static variables to be a problem for GC:

 internal class Helper
 {
     private static List<string> someVar = new List<string>();
     internal Helper() {
         someVar=new List<string>();
     }
     internal void someFunc(string str) {
         someVar.Add(str);
     }
     internal string[] someOtherFunc(string str) {
         string[] s = someVar.ToArray();
         someVar=new List<string>();
         return s;
     }
 }

Here, under low-memory conditions, someVar threw a null pointer error, which in my opinion can only be caused by GC, since I did not find any code where someVar is actively nullified by me.

I think the memory increase slowed down since I actively set the biggest array variables in the most often used Controllers to null, but this is only a gut feeling and not even nearly a complete solution.

I will now do some profiling using the link you provided, and get back with some results.

Answer 1

We need to implement code for memory management too like in your web api code try adding using block for connections like File connection, DB connection etc so that the control resources are automatically disposed.

Web api is just a layer on .Net to have the loosecoupling and services on http based services. But you need to implement the functionality of .Net to optimize the memory managed code in a more better way

Avoid Using Static References

Delete Unmanaged Objects When You Are Done Using Them

Release Objects as Soon as You’re Done Using Them

Use caching to improve Performance

Use Parallel Programming in Web API for async calls

Hope this helps

Answer 2

Shouldn't C# have automatic garbage collection?

C# is a programming language for the .NET runtime, and .NET brings the automatic garbage collection to the table. So, yes, although technically C# isn't the piece that brings it.

Shouldn't it be easy for GC to collect the garbage of a WebAPI application?

Sure, it should be just as easy as for any other type of .NET application.

The common theme here is garbage. How does .NET determine that something is garbage? By verifying that there are no more live references to the object. To be honest I think it is far more likely that you have verified one of your assumptions wrongly, compared to there being a serious bug in the garbage collector in such a way that "It collects objects that are not yet garbage".

To find leaks, you need to figure out what objects are currently held in memory, make a determination whether that is correct or not, and if not, figure out what is holding them there. A memory profiler application would help with that, there are numerous available, such as the Red-Gate ANTS Memory Profiler.

For your other questions, how to make something eligible for garbage collection? By turning it into garbage (see definition above). Note that setting a local variable to null may not necessarily help or be needed. Setting a static variable to null, however, might. But the correct way to determine that is to use a profiler.

Here are some shot-in-the-dark type of tips you might look into:

• Look at static classes, static fields, and static properties. Are you storing data there that is accumulating?
• How about static events? Do you have this? Do you remember to unsubscribe the event when you no longer need it?
• And by "static fields, properties, and events", I also mean normal instance fields, properties and events that are held in objects that directly or indirectly are stored in static fields or properties. Basically, anything that will keep the objects in memory.
• Are you remembering to Dispose of all your IDisposable objects? If not, then the memory being used could be unmanaged. Typically, however, when the garbage collector collects the managed object, the finalizer of that object should clean up the unmanaged memory as well, however you might allocate memory that the GC algorithm isn't aware of, and thus thinks it isn't a big problem to wait with collection. See the GC.AddMemoryPressure method for more on this.