Monday, August 25, 2014

ANTS Memory Profiler Walkthrough - Part 1



Using ANTS Memory Profiler to track down a memory leak in a WinForms application

This walkthrough shows how to locate a memory leak using a sample application called QueryBee. QueryBee is a simple WinForms application for running queries against SQL Server databases. It has a database connection dialog and a query window to query the database. We know our application is leaking memory, because every time we open a query window and close it again, our memory usage increases.

When you open the profiler, you first see the Startup screen:



Figure 1. The ANTS Memory Profiler startup screen.

Here, there’s a list of your recent profiling sessions so you can re-run them easily. For this example, we’ll start a new session by clicking New profiling session.

The New profiling session screen is displayed:



Figure 2. It's easy to configure and start a new profiling session.

All we need to do is point it at QueryBee, choose our performance counters, and click Start profiling.

The profiler starts up QueryBee and begins collecting performance counter data:



Figure 3. Whilst profiling, ANTS Memory Profiler collects performance counter data. The profiler is telling us that it's profiling our application. There are also some useful instructions on this screen telling us to take and compare snapshots.

Taking and comparing memory snapshots is a key activity when looking for memory leaks, so our approach will be as follows:
  1. Wait for QueryBee to open.
  2. Take a first snapshot without using the application; this first snapshot will be used as a baseline.
  3. Within QueryBee, perform the actions that we think cause the memory leak.
  4. Take a second snapshot.
  5. Examine the comparison that the profiler shows us after it has finished taking and analyzing the second snapshot.
So, QueryBee is open, sitting in our system tray.
At this point, we take a first snapshot, which we will use as a baseline for comparison with later snapshots. 

When we click the Take Memory Snapshot button, the memory profiler forces a full garbage collection and takes a snapshot of the heap memory it is using.



Figure 4. Results from our first snapshot – Summary screen.

Now, we go back to QueryBee and perform the tasks which we think cause the memory leak.
We open up QueryBee and connect to a database.


Figure 5. QueryBee – Database connection dialog.


Figure 6. QueryBee – The query window.

The query window opens up and we enter and execute a SQL query.
We obtain some results and close the query window.



Figure 7. QueryBee – The results are displayed in a grid.

We close the query form.At this point, the window is gone. We expect the memory usage to fall back to where it was in the first snapshot, but that is not the case.


Figure 8. Despite closing our query window, the memory usage has not fallen.
So what's happening here? We take a second snapshot and get the results.


Figure 9. The summary pane compares the results of the two snapshots.

A number of problems are highlighted by the summary screen.
  • We can see a large memory increase between snapshots, which we noticed on the timeline (top left).
  • The Large Object Heap appears to be fragmented, which could cause problems (top right).
  • The Generation 2 heap accounts for a large proportion of memory usage - often indicating objects are being held onto for longer than necessary (bottom left).
We can choose to select one of the largest classes which are shown to us in the bottom right of the screen, but instead we switch to the class list to find out more. The class list gives us a fuller picture of what's in the snapshot.

We're interested in objects which have been created since the baseline snapshot, so we need to look at types which have more instances in the second snapshot. We therefore sort by Instance Diff in decreasing order.


Figure 10. The class list allows you to compare memory usage in both snapshots in more detail.

The String class has been placed at the top of the list, with over 300,000 new instances. We want to understand why there is such a large increase so load the Instance Categorizer for the String class by clicking the Instance retention graph iconicon.





Continue.....


ANTS Memory Profiler



Source: http:www.red-gate.com/products

.NET developers use ANTS Memory Profiler to:

  • Find memory leaks within minutes
  • Optimize the memory usage of your C# and VB.NET code
  • Profile your code's use of unmanaged memory
  • Create better performing, less resource-intensive applications
  • Available as a standalone tool or as part of our .NET Developer Bundle
 
Why ANTS Memory Profiler?

Automatic memory management in .NET makes development a lot easier, but it's still easy to introduce memory leaks into your application. For example, forgetting to unregister event handlers can lead to significant chunks of memory being held on to unnecessarily, but spotting that this is happening can be very difficult.

Trying to understand memory problems without a suitable tool can take hours or days, if you're lucky enough to know a problem exists. This is time which would be better spent fixing the problem.

A tool every .NET developer should use


ANTS Memory Profiler makes memory profiling simple. With it, you can:

  • Obtain clear, meaningful results, making it easier for you to interpret the information. Spend your time fixing problems instead of struggling to understand them.
  • Get results fast – with a footprint of less than 32 MB, the profiler can comfortably profile large, complex applications, with virtually no overhead. Take as many snapshots of the heap memory as you like, in seconds rather than minutes.
  • Quickly visualize the relationship between your objects – use the instance retention graph to quickly see why your leaking objects are still being held in memory. You don't have to build a mental map to keep track of how objects reference each other.
  • Go straight to the source of the problem - intelligent analysis highlights the most likely causes of issues, often saving hours of problem-hunting.
  • Zero in fast on the causes of memory leaks – powerful filtering options allow you to cut through the noise, enabling you to quickly get to the root of even the most complex problems.

Feature list

  • Instance retention graph quickly allows you to see the shortest reference paths to all GC roots, which will need to be broken to fix memory leaks.
  • Profile unmanaged memory use – if your .NET code uses unmanaged code or components, you can see how much memory unmanaged modules and classes are holding on to.
  • Compare any two snapshots with each other. Support for snapshots up to 4GB.
  • Ability to take and analyze an arbitrarily large number of memory snapshots.
  • Automated API for taking snapshots from within your application using a single line of code.
  • One-step setup dialog.
  • Capable of attaching to a running .NET4 process. Ideal if you want zero downtime and to preserve the state of your current process.
  • NEW: Assembly loading view to let you explore memory consumption from static and dynamic assemblies.
  • Ability to profile .NET executables, ASP.NET applications and web services in IIS, IIS Express, and Web Development Server, SharePoint 2007 or 2010 collections, Silverlight applications, Windows services, COM+ applications, and XBAP applications.
  • Native Windows Presentation Framework (WPF) support.
  • Integration with Visual Studio 2005, 2008, 2010, 2012, and 2013, so you can start profiling your application from within your IDE. One click launches ANTS Memory Profiler within seconds, with the executable path already set.
  • Supports .NET 1.1 to .NET 4.5, in any language supported by the .NET framework.