Troubleshuting memoryleak on IIS 6.0 App. Pool.

[pesko]

Hi

Does any one know how I can see how mutch memory every application pool use - virtuel and fysical?

And what part of my dot net aplication that is leaking memory?

pesko

[CoffeeFiend]

You can monitor the worker process' (aspnet_wp.exe for IIS5 or w3wp.exe for IIS6) memory. There are some performance counters you can look at also (for IIS, the .NET CLR, ASP.NET and ASP.NET apps)

There are some settings you can change in machine.config so it recycles the worker process if it eats up too much resources (i.e. processModel)

Look at the event logs! Look specifically for events like this:

A worker process with process id of '1234' serving application pool 'DefaultAppPool' has requested a recycle because it reached its virtual memory limit.

or

A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '1234'. The process exit code was '0xc0000005'.

That alone should be enough to find the culprit.

There's also some IIS diagnostic tools worth trying.

But your main issue here is finding your source of problems. For all we know, it could even be someone abusing the session objects, putting tons of data there. Combine that with long sessions and you've got very high memory usage - but not a memory leak (even though it will look similar). Or some process working with ridiculously large datasets.

You can move the session state to see if that helps (will only help if you're abusing the session obj - not if there's a leak, but would rule out a simple yet common problem).

But really, if you want to do more than that, it gets quite a bit more complicated. You can dump the memory (big files!) and check the managed heap for some clues, look if there's GC issues, look at the cache, etc. For this you'll need the Windows Debugging Tools. And don't expect no simple GUI, point-and-click stuff, because WinDbg isn't it! (more like pages full of hex numbers) If it comes down to that, you might have to hire someone to do that for you. You can try running a profiler too (can't hurt).

But honestly, I'd try the session thing, and having a look at the code built in-house (if there's any), see what kind of mess it is. If ASP.NET apps leak memory like that, there's a big problem somewhere! And sometimes, it's a seat-to-keyboard interface that is (the one who can't write code that works to a basic level). We've made countless ASP.NET apps (even some were made by a webmaster - not a programmer at all), and none so far with such bad issues.