Identifying memory problems in an ASP.NET application

Question

Hey,

I've got an ASP.NET application running and on the production box it's using about 450MB RAM, however, it shouldn't be using quite so much, and it seems to increase over time, so it seems there might be a leak or atleast something not being released properly.

I took a look with PerfMon and there was 416MB in GC Gen2.

Anyone have any idea for finding out what it's keeping in memory? Could I just grab dotTrace/ANTS and somehow attach it to my IIS (6 - on windows server 2003) - or is there a better way? :-)

Thanks.

Answer 1

Although this is a specific blog about a technology you're probably not using it does cover how to diagnose memory issues - http://blogs.msdn.com/tess/archive/2008/09/12/asp-net-memory-issues-high-memory-usage-with-ajaxpro.aspx

Dig through Tess's work, she's got a lot of debugging/ diagnosis posts and I'm sure you can find more which are of use to you.

Answer 2

Are you properly disposing of objects of classes that implement IDisposable? This would include SqlConnections, SqlCommand, SqlDataAdapter, DirectoryEntry, etc. Do you have any objects that use unmanaged memory that don't implement IDisposable (and/or aren't getting disposed)?

Answer 3

Watching this TecheEd presentation by Tess would be a good start.

She demonstrates using adplus to take a dump of an ASP.NET application that is consuming a great deal of RAM, then loading that dump into WinDbg for analysis. Use the !gcroot command in WinDbg to find unexpected roots and go from there. She advises against storing complex types that contain references to other objects in cache or session.

Answer 4

I am pretty sure that you have been through all the motions already by now, but i had a similar problem on a site i maintain.

The site was using roughly a gig of memory on the server , and much check and cleaning , we had to get rid of a lot of session calls as they were not being disposed of correctly.

Also it turns out that on a site of my site with the amount of concurrent users that i had , the rough estimation of a gig was just what it needed.

It also turns out that loading a lot of user controls on a page puts a bit of strain on server memory , not sure why but it did help us pinpoint some issues by removing the user controls and making them into smaller pages.

Last but not least check what type of session provider you are using , if inproc is putting too much strain on you server maybe its time to change to the the asp.net state session service or using a sql server as your session provider.

Let me know what you think and if you found and specifics.

Answer 5

The classic problem of newing up a bunch of strings in a loop could cause the issue you're seeing due to large amounts of memory being allocated for new strings without releasing them. Are you using StringBuilder where appropriate?

Answer 6

I really enjoyed watching Tess' presentation - and I took a memory dump and analyzed it with windbg. I haven't completely locked down the cause yet, but I think Søren was really on track too with the strings. At least I have 280MB strings in my memory dump - and I know there's not many StringBuilders in the application.

Answer 7

Are you properly unwiring event handlers everywhere? I'm told that they might be sitting around if you never detach them from the event. They might be keeping references to larger objects longer than necessary.