Wednesday, February 11, 2009

I wrote before about not believing in regular system reboots. One of the services we wrote had a serious memory leak and process size grew over 1GB within 2 days requiring us to perform regular service restarts. This is not something that we were able to replicate in development or QA environment so I’ve decided to do some production debugging.

From the File Menu, select “Open Dump File” and open the created dump file from C:\temp\LeakDump\

Load SOS debugging using command .load SOS

Now the fun begins :)

Run !dumpheap –stat What you’ll see is that the most memory is used by data type is System.String (53MB) and Dictionary+Entry (22MB). Also notice that there are more then 1 million string entries. Most of them are very small (<55 bytes average).

To see the entries. Use command (Press CTRL+BREAK to stop the flow) to see the list of addresses. !dumpheap -type System.String -max 100 !do 022b8978 Substitute the address of one of the items instead of the 022b8978I underlines a Text String that you can see. In my experience of debugging my apps, based on the data, I can tell what is stored, and probably have some ideas about where that data is generated or should it be cleaned.

Run !gcroot [Reference] to see exactly what class is holding a reference to the object

A walkthrough like this will not necessary solve a problem in the application, but it can point out to a possible issue in the application that can be solved. To me, a memory leak is not a problem that should be ignored, but is a bug that can be fixed.