Memory leak

[Chris]

Hi,

I have an asp.net site that receives a medium amount of traffic (500-1k
users per day). I'm having massive trouble at the moment with a memory leak
that I just cannot isolate. The server is w2k, with 1GB ram, but the
asp.net process is recycling 2-3 times daily!

I've run perfmon over the last week to get a clear picture, and here's what
i see from it:

Looking at the 'private bytes' counter, it increases quite quickly from
around 1MB to 750MB in a matter of 6-12 hours (depending on load).

Gen 0 and Gen 1 are behaving as expected, never get very big, and are
relatively flat.
Large Object Heap, whilst bigger, is also flat, so not a contributor.
Gen 2 however is increasing at pretty much exactly the same rate as private
bytes, and never gets recycled except for when the asp.net process itself
recycles, or IIS gets reset.

I've read some good articles on msdn about this, but i'm afraid they weren't
too much help. I am hoping that someone has come across Gen 2 not recycling
before and has a few pointers as where to look next.

Cheers

Chris

 

[Alvin Bruney]

before you dive into mucking with generations etc, back up a bit and
re-examine your data structures and resource alloc/deallocation.

If you use datasets/datareaders, are you being carefull to null them out
when they are no longer in use. Are you closing your connections. Have you
guarded blocks of code with a finally construct or a catch handler to ensure
that resources are being cleanup up neatly. Have you considered replacing
string concatenations with stringbuilder for intense string manipulation.
Are you examining the number of exceptions and where they are coming from to
determine if they are causing memory leaks. Are you making use viewstate to
ease the load on the server. are you using caching effectively instead of
establishing new connections to grab repeat data requests?

The solution is probably in these unanswered questions. When you start
scaling a web application upward, these factors collectively make or break
an application.

 

[Chris]

Thanks for the post.

For the most part, yes I'm cleaning things up. I've had a couple of good
combs through the code, and yes, I found one or two places that I had to
tidy up, but for the most part everything that has a dispose method is being
called.

I don't explicitly set objects = null, as it's my understanding that you
don't need to do this anymore! Am I wrong? And if so, do I have to set
anything that's not a value data type = null when I'm done with it?

all connections are being closed, string manipulation is done with
stringbuilders, all resources are being cleaned up when using try/catch. I
do get on order of about 20-30 exceptions per day, however the majority of
those are time-outs on a page where the user can upload files. I've
experimented by disabling that functionality for a day, but there was no
impact on memory. I've gotten rid of viewstate as much as possible because
it only causes problems with some users. Some people just constantly get
viewstate corrupted messages.

There are a couple places where I could use caching more effectively,
they're on my to do list, *but* that's a performance issue, and shouldn't
be causing a memory leak.

I guess I don't understand what all this crap m$ are putting out about GC
and managed memory when it was just simpler when you had to clean up after
yourself.

Cheers

Chris

 

[Kevin Spencer]

Are you using any Interop in your application? Managed code cleans itself
up, but Interop doesn't necessarily. The most common cause of memory leaks
is unmanaged code.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Chris]

No, no interop.

I've even replaced the standard .net email code (which uses unmanaged code)
with a managed 3rd party component. (which didn't make any difference!).

Cheers

Chris