aspnet_wp.exe memory leak questions...

[Rishan]

Hi,

I'm trying to debug a memory leak on a production application for one of my
clients. The aspnet_wp.exe, if left to grow, will eventually consume enough
memory to throw an out of memory exception.

The thing that was unexpected is that most of the memory is not in the heap.
The current usage stats are:

total memory consumption of aspnet_wp.exe: 400MB

# bytes in all heaps: 180MB
gen 0 heap size: 12 MB
gen 1 heap size: 1MB
gen 2 heap size: 160 MB
Large object heap size: 8MB


Other info:

-.Net framework 1.1
-Total physical memory: 4 GB
-Server only hosts the one asp.net application, database exists on another
server
-Session State is SQL Server, so all session information is stored on the
database.
-about 40 concurrent users.
-it grew to 400MB in about 7 days.

My question is: What is making up this extra 200 MB? (stack information?)

Thanks in advance,

Rishan

 

[Benjamin Strackany]

First thing you should do is configure your application pools so that you
don't get the out of memory exception. It can happen a lot with vanilla
Windows servers with 3-4 GB of ram. Read more about it here:
http://www.developmentnow.com/blog/2004/09/systemoutofmemoryexception-with-aspnet.html

To dig into th ememory some more, you could try out the demo version of Red
Gate's ANTS profiler:
http://www.red-gate.com/products/ants_profiler/index.htm
It'll show you exactly where all the memory is going. I wouldn't worry so
much about the 200mb (that's small), but more about what's leaking. You're
probably getting the exceptions when your pool hits 1.6-1.8gb of memory.
That's a lot.

 

[Rishan]

Ok, i believe I've answered my own question...

I took two "dumps" of the aspnet worker process. One last week when it was
200MB, one this morning when it was 400MB.

The private bytes has consistently been about 170 MB for both dumps, and is
170MB right now...

The managed heap size has made up the difference in size. This week it was
180 MB, last week it was 100 MB, right now it's 30MB (it's been an hour
since the worker process was recycled).

So, it looks like I have a leak in my managed code. Looking at the heap
details, the main difference is the number of allocated System.String
objects (which are probably rooted elsewhere). The strings don't seem to be
rooted in Datasets or Datarows (80,000 allocated for both dumps)...so I'll
have to dig a little deeper for more info...

Rishan