CODEWITHSUNDEEP
asp.netiis-7memory-leaksgarbage-collection
Geoffrey McGrath
Geoffrey McGrath

Reputation: 1673

Chasing down a memory leak on legacy ASP.Net website

I have a legacy ASP.NET website consisting of over 230 unique .ASPX files. This website has hundreds of thousands of hits per day across many of the different files. It leaks memory, causing periodic process recycles throughout the day (Windows Event ID 5117: A worker process with process id of '%1' serving application pool '%2' has requested a recycle because it reached its private bytes memory limit.)

I've already tested the 30 most-frequently accessed pages and fixed the memory leaks in several of them, resulting in a significant improvement. And load testing of those pages show they don't leak any more. But that leaves over 200 pages that still haven't been checked. But with 200 more files to check I wonder if there isn't something a little more organized or clever that can be done.

For instance, is there instrumentation that could be added to the Application_BeginRequest or Application_EndRequest event handlers in the Global.asax? If so, what specifically should be monitored? Example code and/or discussion would be most helpful.

Upvotes: 2

Views: 620

Answers (1)

Dan But
Dan But

Reputation: 658

The best tool you can use to get organized and plug your biggest leaks first is windbg.

It comes with the windows sdk

heres a reference

http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx

It can be a little tough at first to get used to the commands but heres what youll want to do.

1. Install windbg on a machine that is running the site
2. Load test all the pages and get the memory usage way up
3. (optional) Force garbage collection with gccollect()
4. Attach to w3wp.exe with windbg
5. load your symbols (.pdbs and the clr and sos)
6. dump the memory (!dumpheap -stat)

This will show you a sorted list by the number of objects in memory. When you have a leak you start to build up tons of the same object.

You need to dig deeper to get the size of these objects

1. The first number in the row will be the method table copy this number
2. Dump the method table (!dumpheap -mt #######)
3. Choose a single objects ID from the first column and copy this number
4. Get the size of the object (!objsize #######)

( # of objects) X (size of single object) = size of the leak

Find the classes that are taking up the most space and plug them first.

This may help too - CLR profiler http://www.microsoft.com/en-us/download/details.aspx?id=14727

Upvotes: 2

Related Questions