String/mscorlib.dll leaving massive live count
essjay
Posts: 3
Hi All,
I'm using the ANTS Profiler to test the memory of our ASP.NET 1.1 website that is giving loads of trouble. Our host has limited us to a 256Mb application pool and this is resetting every few seconds due to a memory leak somewhere. Basically we're losing sales because no-one can stay logged in long enough to buy from the website.
I've refreshed the home page 20 times and taken a snapshot of it. In the "All Classes" view I can see a live count of 0 for any of the classes I coded, but when I look at the mscorlib.dll module for example, the String class is leaving the following:
Live count: 11,177
Live size: 585,484
Total size: 8,407,560
How do I find where the memory leak is? Are all my strings just hanging around even though there's no instances of my classes still alive? Any suggestions how I get rid of them?
THis is my first steps into investigating memory leakage to be nice....!
I'm using the ANTS Profiler to test the memory of our ASP.NET 1.1 website that is giving loads of trouble. Our host has limited us to a 256Mb application pool and this is resetting every few seconds due to a memory leak somewhere. Basically we're losing sales because no-one can stay logged in long enough to buy from the website.
I've refreshed the home page 20 times and taken a snapshot of it. In the "All Classes" view I can see a live count of 0 for any of the classes I coded, but when I look at the mscorlib.dll module for example, the String class is leaving the following:
Live count: 11,177
Live size: 585,484
Total size: 8,407,560
How do I find where the memory leak is? Are all my strings just hanging around even though there's no instances of my classes still alive? Any suggestions how I get rid of them?
THis is my first steps into investigating memory leakage to be nice....!
Comments
Thanks for asking. This is a common comment we get when you attempt to memory profile ASP .NET. The issue is that because HTML is completely character-oriented, just about every output is converted to a string. The result is that you are confronted with tens of thousands of string objects, leaving you a bit snow-blind at the results.
What I normally advise is to try to ignore all of the string objects and concentrate on your own classes instead. With ASP .NET, if a string is hanging onto memory, chances are that the real cause is a class up the call stack somewhere anyway. I'd say to look at the all classes tab first and see how many objects have a high live count that are not strings and work from there.
The other problem with ASP .NET is that server configuration can affect memory usage almost as much as code. If sessions are left open for days-on-end, your code may be just dandy but your server administrator is letting it down. There are also 'mysterious' ASP .NET processes that you just don't have any control over as well.
Hopefully you can find the leak!
Many thanks for your reply.
This memory leak is starting to stress me out. From what I can see, all my classes are being destroyed by the GC.
All my host has told me is "All we can see here is that something in your code is reserving a lot of memory for itself (even though it typically only ends up using ~10% of this) Sometimes this is trying to reserve more than 256megs and this is what is causing the application pool to recycle."
Anyway - so should I essentially be ignoring any classes where the module name is "mscorlib.dll"? See below for an image of my "All Classes" view:
You may also want to look into the disparity between the total memory used and the 'managed' heap size. In particualr, compare task manager against what perfmon's .NET CLR memory/#bytes in all heaps says. .NET may be grabbing more memory than it's supposed to. It tends to reserve far more on startup than it actually needs; this is just 'normal'.
You can figure out which process you want to look at in task manager by running cscript iisapp.vbs, which will give you the PID for each worker process.
If the memory usage is creeping up gradually, then there could be something wrong with the garbage collector. (re-install the Framework?)
A lot of data on the large object heap can also cause fragmentation, which makes allocating memory harder for the .NET runtime because the heap doesn't compact as well and the process ends up using more memory than it should. The fix for that would be a redesign of the application to use 'smaller' objects.
At any rate, ANTS Profiler doesn't seem to be revealing anything about problems in the code, so I'd say it's a server configuration issue.