Use. NET Memory Profiler to diagnose. NET application memory leaks (methods and practices) __.net

Diagnosing. NET application memory leaks using. NET Memory Profiler (methods and practices) Blog Categories:Troubleshooting & tuning. NET asp.net loadrunner ASP algorithm

The application diagnosis and optimization of friends know the memory leak and the harm caused by this situation is generally difficult to analyze and locate, especially in. Net/java applications, implicit heap memory management and complex referential relationships between managed objects complicate the analysis and positioning problems. This article with my understanding, as far as possible explained:

A method of memory leak analysis and diagnostics applied to the. Net/java managed memory class, using the. NET Memory Profiler tool to sample the analysis and diagnostic practice process of a memory leak problem in a real asp.net application.

This article includes the following issues, insufficient:

This article is written in my existing understanding, especially the "method" related content, each person in different situations will have different ways; instead of a comprehensive explanation of the. Net Memory Profiler Tool, the functionality involved in the practice is only to locate problems in asp.net applications here. Refer to the. Net Memory Profiler documentation. . Net/java memory leak analysis and diagnostic methods for managed memory class applications

First of all, some popular science knowledge, understanding of the brothers please do their own quick jump.

In managed memory management, the "leak" meaning differs from the forgotten explicit release (delete/delete[] in traditional Native applications), and it is necessary, of course, for unmanaged resources such as handles, or in the Finalize (the destructor is equivalent to Finalize) method, which is explicitly disposed in the the "Leak" object instance in managed memory management refers to the fact that the GC thread is not allowed to be freed, even though it is no longer used, because there is a referential relationship that should have been disconnected from the object in the Root object set. In most cases, because the application (the programmer) thinks that the object will not exist, and when it is reused, and then creates the object instance again in the managed heap, it can be imagined that the consequences are serious and that the heap memory will be full as the number of creation increases. (The G3 zone in the managed heap is full and the G2 area cannot make room).

The GC determines whether an object can be freed by traversing all the objects and child objects referenced by it, starting with the root object, such as the args parameter of the Main function, the static variable, and its object members. GC executes by marking objects in these references, clearing unmarked objects to complete memory release (tagging, Cleanup algorithms), and, of course, purging may be step-by-step (such as transferring Finalize queues, etc.). Due to performance considerations such as marking, the interrupt time of the cleanup algorithm, the managed heap partition (generation), the current CLR is 3 generation –g1, G2, G3. With age (GC 1) increases, the object will gradually transfer from G1 to G3 generation (copy, collation algorithm), that is, G1 is the Cenozoic, are some short-term objects, G3 is the permanent residence of the elderly object. It is necessary to note that there are actually 2 managed heaps (SOH and LOH) in the current version of the. NET CLR, one of which is called the large object managed heap (LOH), which is designed to store objects larger than the 999 Bytes. Programs can allocate object space only in SOH G1 and LOH, and only CLR GC threads can allocate (transfer) objects in SOH G2, G3.

To understand the basics above, take a look at the legend of the memory leak in the managed object instance:

The meaning shown in the above figure is that after a period of time, the object in the heap is referenced to the Root object, where the color from shallow to deep indicates the age factor. If the GC thread is executing at this point, the heap situation will look like the following:

All of these unreachable object instances are freed by GC so that the managed heap memory is properly reclaimed. However, it is necessary to note that if you are in a reachable area where the GC is not released, there are some referenced objects that will not be used later, and "leaks" occur when the application (the programmer) creates a new object in the next use. When the business involved in creating an action on such an object is repeatedly executed by the user, the G3 generation of the CLR is gradually growing, and the service will not die far.

With the above knowledge, it can be said that the structure of memory leakage diagnosis, positioning methods are as follows:

Monitor the managed heap usage (as well as the memory footprint of the process) to find a business with a long memory that is in danger of leaking memory. This process I usually use LoadRunner script to do, after all, small size object leakage takes a long time to occur, rely on manual operation is not reliable. This generally does not require concurrency; Restart the application, let the managed heap clean up unrelated objects, perform a 1th-step discovery of a memory leak defect business; Use the tool to export the managed heap (dump) or take a snapshot of the managed heap (snapshot). Make a comprehensive GC (full GC) before Dump/snapshot, and try to release the objects as clean as possible, eliminating distractions. The leaking object is no longer GC-dropped, will be saved in the managed heap, will be dump/shot, repeat step 3. This will again create the object that was leaked at the last execution (step 3), and repeat step 4. At this point, the leaking object exists as a new object for this dump/shot, as opposed to the same kind of objects that were leaked in step 4; By comparing steps 4 and 62 dump/snapshot results, it is necessary to find the leaking object/object type in the vast objects. In fact, this process is relatively difficult, need to understand the application design, relevant background knowledge, the more detailed, the faster the positioning, the results more accurate and complete. The purpose of doing two times dump/snapshot is that the leaking object will belong to the "new" create object set scope, which will effectively narrow the scope of the object to be examined. It should be explained that the "new" here refers to the second dump/snapshot relative to the first dump/snapshot existing in the new object, may be the previous step of the scope of the object is relatively large, the next can be sorted from the object type angle check order of precedence: Examine objects that apply a type in the namespace, examine objects of the type provided by the framework, and check for objects that have performed a manual shutdown/release method. such as the Dispose method of the IDisposable interface in. NET. Because once this method is invoked, the object should have been freed by the GC, and it should not exist again. For this type of object, there are possible reasons for this:
A Being referenced by a short lifecycle object, such as a local variable (including a shape parametric), causes the GC to fail. However, when the dump/snapshot is executed again, it should have been released by GC.
B The "Pool" is designed in the application, and although the object is closed, it is still stored in the pool for the next time it is used. This is generally rare, especially in. NET, where objects placed in a pool rarely call their Dispose methods. Java is similar in this regard.

In fact, the structural approach is to express only meaning, the real process will be a step-by-step positioning, iterative process, in understanding the meaning of the premise, flexible use. After locating the leaked objects through a series of analysis and diagnostics above, find out which objects they are referenced by, that is, which objects in Root Path, by modifying the code to cut off references that should not exist, so that the leaking object can be unreachable in a normal state, GC Threads will also handle them correctly. In fact, the focus is still on analysis, diagnosis, positioning, repair method is very easy to find.

troubleshoot asp.net application memory leaks--. NET Memory Profiler Tools Practices

The first thing to look at is what. NET Memory Profiler is, not translated. I understand that it is actually a snapshot tool for the managed heap, which can mark unmanaged resources. The ability to show real-time heap usage of graphics is really not a big use.

. NET Memory Profiler is a tool for the. NET Common Language Runtime This allows the user to retrieve information about all Instance allocations performed on the garbage collected heap (GC-heap) and all instances of that reside on the GC heap. The retrieved information is presented at real time, both numerically and graphically.

Again, this ASP.net application, the first two days of the department of a asp.net application has a memory leak. The phenomenon is that, in a query business scenario, after discovering the query several times, the w3p worker process of IIS grows several megabytes, more than 10 trillion, several 10 megabytes of memory (this is proportional to the query result size), and through Perfmon monitoring you can see that the CLR of the w3p executes the GC in time, but the managed heap usage always increases not Minus until the service is down (w3p crash in the LoadRunner test).

There is no detail about using the. NET Memory Profiler tool to use the details, and I'm sure we can see the friends here, the basic use of this tool will not be a problem. Let's talk directly to the point below.

According to the method provided above (structured diagnostics and location method for memory leaks), we have already found the business in question and can reproduce it. The service is then restarted to allow the w3p managed heap to be initially clean and exclude extraneous objects. Then perform a problematic business, where I use the LoadRunner vuser playback test script. The next step is to ask the. NET Memory Profiler To do the snapshot of the w3p process hosting heap. Before each snapshot. NET Memory Profiler automatically makes a full GC. Do a query business again, then do snapshot. After two comparisons you can see the following:

You can learn from the following:

All that is displayed is the contrast between the two snapshots of 3# snapshot and 2# snapshot;. NET Memory Profiler provides all the types of objects that are photographed Types, show Types can specify the range of display types, including all, "new" objects (The second dump/snapshot relative to the new object existing in the first dump/snapshot), type details each type of object instance information, Instance details of each instance; Call stacks/ Methods method call stack; Native memory unmanaged memory information, and also note Field Sets, including Standard, Dispose Info, Heap utilization, to filter the displayed Types type results. It is useful to see what type of object is still in after the Dispose method call mentioned in the previous method, which narrows the scope of the check, which is covered below.

The next need to be targeted for one after another, the way to first consider which type of object is most likely to leak. Priority levels are provided in the above method. I'm thinking about this here because I know that in a business page with a problem, there is a static type of member variable that is an object of type XmlDataSource, because static so the instance is not GC, So it makes sense to check which object instances it references. Viewing the details of this type is visible:

The unique XmlDataSource type instance is the #13, number No. 483 (global instance number) object, where you can see the set of objects referenced by the following details:

After examining the objects referenced, it was found that, #13, the XmlDataSource type instance of number No. 483 referred to 6 Xmldatasourceview objects (6 because I did 3 snapshot, each LoadRunner test In the script, 2 query operations are performed, and the age can be seen through multiple GC, but none is released.

The reference path to the Root set is also simple, with only one, and they all refer to events in the #13, No. 483 instance. With this analysis, we can find a reference relationship with the static XmlDataSource type object, which results in a memory leak because the Xmldatasourceview type object generated by each query cannot be reclaimed by GC. The workaround is also simple, by making the XmlDataSource type object in the page a non static member variable.

By fixing the leak problem above this object, we can save nearly 11M of managed memory per business. But with previous monitoring, the amount of memory added to the business is much larger than that, and by fixing the problems above, it does not fully address the continuing rise in memory. It can be concluded that there are other locations where memory leaks exist in the business, which requires continued analysis and diagnostics. This time I started with the Dispose Info, which said that. NET objects should no longer be used and reclaimed by GC after a program calls the Dispose method, and should be concerned if the GC has failed to recycle multiple times after the snapshot has found the Dispose method executed. The following is the object type after Dispose:

Sure enough, you can see in our business page and its Master page objects are all executed Dispose, but not GC dropped. By opening the type details to see what can be found, they are all referenced by the SITEMAP.

We all know Sitemap and Xmpsitemapprovider asp.net 2.0 site Map components, which are provided and managed by the. NET Framework, we are configured through the site file, so what is the cause of this. Through the investigation to understand that the Sitemap object Sitemapresolve event is static, and Sitemap is global nature, as long as we subscribe to these pages Sitemapresolve events, will be referenced to the sitemap. Interested friends can see the sitemapresolve causing memory leaks section of MSDN Sitemap::sitemapresolve Event. Also, from the object Tree memory usage is more reasonable, each page because of the inclusion of a large number of controls and their state data, so are very large, each Page object has more than 46M.

written in the last

The whole thing I write is relatively complete, detailed and easy to practice, the main reason is that some people around to find that the memory of the managed heap leakage analysis, diagnosis and positioning is a can be used to "eat" of the work, is very unwilling to share with others. It should be said that the matter is indeed very experienced, this kind of empirical things are willing to stash, and so on when necessary to show off. But what I want to say is that we need to be open, we need to pass on, but all that can be written can be used for words (meaning of words). In an environment that does not advocate sharing, either study it yourself or stay out of it, if there is no thought at all.

Hope useful, please share if you have ideas. Good Night ~

//2009.03.06 01:01 add////

Additional attachment "Lesson2.zip" is an official video of the. NET Memory Profiler Memory leak analysis and diagnostics. The version used is a bit old, and the example application is too simple, but some of the hints are worth considering.

. NET Memory Profiler Web site

//2009.03.07 13:23 add////

Author: lzy.je
Source: http://lzy.iteye.com
This article copyright belongs to the author all, only allows the summary and the full text two forms reprint, does not allow to cut the text. This statement must be retained without the consent of the author, and the original connection is made in the obvious position of the article page, otherwise the right to pursue legal liability shall be retained.