ASP.net Web Application :: Memory Leak Detection Strategy

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
nmartin
Posts: 2
Joined: Mon May 28, 2007 3:03 pm

ASP.net Web Application :: Memory Leak Detection Strategy

Post by nmartin » Mon May 28, 2007 3:25 pm

Hello, we have just purchased the .NET Memory Profiler (Today ;-) and having watched the video tutorials, I was hoping that perhaps someone could provide me with some guidance on the following...

Background:
We have been suffering from irregular performance on our production web site. Our ISP has told us that this is because our ASP.net (v1.1) application has a memory/resource leak. Quite possible as we have never checked/analyzed the development.

To try and identify the problem, and to prove/disprove our ISPs statement, we have purchased the .NET Memory Profiler. Our (simplistic!) approach has been as follows:

1) Open the web site's URL in the Memory Profiler.
2) Wait for the default/home page to load and take a snapshot.
3) Either refresh the home page and/or browse around the web site and then take another snapshot.
4) Open the 'Types' tab and set the filter to 'With new or removed instances' and set the view to show 'Dispose Info'.
5) Sort the Live instances -> Delta column and review which have a positive entry.

Actually we 'only' have 4 entries:

System.Web.Caching.CacheDependency Delta = 5
System.Web.DirMonCompletion Delta = 2
System.Web.DirectoryMonitor Delta = 2
System.Web.Bitmap Delta = 2


The question is is whether this approach is valid for what we are trying to achieve, i.e. a well managed web application, or whether there is a better approach or perhaps something additional we should be testing?

Any help/guidance would be much appreciated.
[/list]

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Tue May 29, 2007 8:54 pm

I think the approach you're describing is a valid approach. However, I suggest that you don't only look at disposable instances (selecting the "Dispose info" field set will filter on disposable classes). Unless you are specically looking for a resource leak, it is a good idea to investigate all classes with new instances.

The numbers you included are not very alarming, but if the number of instances keeps increasing you might have a problem. Some things you could look for are cached items that keeps on increasing, session and view states that do not get collected etc. Since timeout are involved with for instance session states, you might need to run the ASP.NET application for a longer period, preferably using several sessions.
Best regards,

Andreas Suurkuusk
SciTech Software AB

nmartin
Posts: 2
Joined: Mon May 28, 2007 3:03 pm

Post by nmartin » Wed May 30, 2007 7:49 am

Thank you Andreas - we will dig deeper! :-)

rharding98
Posts: 1
Joined: Thu Dec 06, 2007 12:40 pm

Help??

Post by rharding98 » Thu Dec 06, 2007 12:43 pm

Hi I'm also trying to find a leak in our ASP.NET web application but am really not sure where to look. I've got 11 dumps from over 5 hrs of ACT hitting the site and there is so much data I'm at a loss as to where to start. Any help would be greatly appreciated.

Thanks,
RH

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Mon Dec 10, 2007 9:49 pm

If you run a stress test using ACT on your ASP.NET application, it might be a bit hard to locate instances that are part of a memory leak. If you run for an extended period of time, you might be able to identify types that use an increasing amount of memory. Investigating the root paths of these types might give you a clue on why the memory usage increases. E.g. if the root paths contain CacheEntry entries the memory usage might be caused by caching and session state.

If you're looking for memory leaks it is probably a good idea to stop hitting the site and wait for the session states to be flushed before collecting the snapshot. For example, you can use ACT to create a set of sessions, request several pages and then pause to allow the session state to be flushed. Before running the ACT script you can collect a heap snapshot, and after running the script (and waiting for session states to be flushed) a new snapshot should be collected. To avoid waiting for too long before collecting the second snapshot you can lower the session state timeout value. Now you should be able to to compare the snapshots and investigate the types with new instances. Hopefully there will be less data to investigate using this approach, making it easier to identify any potential memory leaks.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 13 guests