ASP.NET Website Memory Usage quite high

Question

I have an ASP.NET website that will hit about 2gb physical memory used within about 3-4 days, which to me sounds really bad. At the moment, I have configured IIS to restart the app pool process when it hits 500mb. I would like to try and track down the problem.

When creating a new instance of an object in .NET, I was under the impression that it doesn't need to be freed as the .NET garbage collector will do this for me.

Is that the case or could this be one of the reasons I am having issues?

Answer 1

.NET will manage garbage collection for you very efficiently. While on types that implement IDisposable it is wise to call the Dispose method, this probably isn't your problem. Memory leaks can happen in .NET for a lot of reasons. Here are a few:

• You cache too much data per user in the Session.
• You cache too much data on an application level in the application cache or in a static variable such as a dictionary.
• You store web controls (or user controls) in the session or application level.
• You hook instances to events on static types or to types that keep being referenced (because they are stored in a cache).

I hope this gives you some ideas about where to look.

UPDATE: You should watch this video about ASP.NET debugging.

UPDATE 2: About your comment on my answer the following. The CLR will collect all managed memory, therefore all object you create using new will get collected. In this sense, it doesn't matter whether an object implements IDisposable or not. There are however many times that you need to use native resources (such as file handles, graphic handles, database connections, use of native -thus unmanaged- memory) directly or indirectly. The CLR does not know how to release these resources. For this .NET has the notion of finalizers. A finalizer is a virtual method that a the developer of a class can implement. When you do this, the CLR will call this method after an instance of that type gets unreferenced and before it gets collected. Finalizers typically contain logic that release these resources. In other words, when a type needs native resources, it will usually have a finalizer method that allow the type to release those resources.

What about the CLR is concerned, the story ends here. The CLR has no specific handling of objects that implement the IDisposable interface. The .NET garbage collector however, is undeterministic in nature. This means that you don't know when it runs and if it runs. This means that it can take a very long time before your native resources get cleaned up (because a finalizer will only get called after a collect). For many resources however, it is necessary to release them as soon as your done with them. For instance, you tend to run out of database connections quickly when you don't close them or when you’re working with GDI+ in .NET through the System.Drawing namespace).

For this reason the IDisposable interface was introduced. Again, the CLR and the garbage collector don't look at this interface. It is a contract between the type and its users, allowing its users to directly release the underlying resources of an object. In a normal design both the object's finalizer and the object's Dispose method will call the same private or protected method that will release those resources. When a type implements IDisposable it is wise to call it's Dispose method when you’re done with it or wrap the object in a using statement to allow the release of native resources to be deterministic.

So to come back to your question. All managed objects will be collected by the GC, but native resources won't. Therefore types might implement a finalizer method and those objects will also typically implement the IDisposable interface. Calling Dispose on them will explicitly and directly release those native resources.

I hope this makes sense.

Answer 2

There could be lots of reasons for your high memory usage, but Garbage Collection in .NET is a very precise thing. That is, it does a lot for you, but sometimes not as much as you'd expect.

Specifically, it can only clean up objects to which there are no active references, so if you're done with a class, but something still has a reference to it, you'll want to remove that reference so the GC can recover that memory for you. Additionally, if you have any inactive open connections (say, to a DB or something) don't forget to close and dispose them. Typically, we wrap such objects in using blocks like this:

using(SqlConnection conn = new SqlConnection(myConnString))
{ ...rest of code here }

This will automatically close and dispose of the connection. This is implemented as a try...finally block, so the connection will be closed even if an exception is thrown in the using block.

Other than that, the answer is "profile, profile, profile" until you find your leak/bottleneck/whatever.