I have a problem with a .NET 4 application leaking memory. It's not a "forgot to clean it up" leak in the normal sense, they are doing compiles that create a bunch of .NET assemblies in memory and they tell me there's no way to clear them out after. So it's now up to me to keep the service going.

So I'm faced with a couple options. There's the "set IIS worker processes to recycle when the memory gets large." That will help, but to me it seems like still an inherently metastable system, and there's user impact while the pool is recycling, isn't there?

They tried breaking out the compiles into separate temporary app domains, but then each operation is pretty slow, it adds ~15 seconds per hit to spawn the app domain. So they don't want to do that.

Is there anything other than "recycle a lot" I can do from the system side to mitigate this problem in a more permanent way? (Or app ideas, but that's more for SO.)


That sounds like a typical programming error. Move the to unload assemblies to their own appdomain and you are fine. This is what I do for stuff like plug ins etc. that I need to be able to unload.

  • Yeah, we're encouraging them to, but naturally they want a server fix because of the separate domain perf hit. We tried recycling but the app locked up after recycle, I think because some hits came in to it while it was initializing. Is there a way to make spawning of additional app domains faster somehow? Seems like a "connection pooling" kind of pattern. – Ernest Mueller Nov 2 '10 at 1:28
  • We've settled on "make them move it to new app domains." If anyone has any tips on making that faster it would be appreciated though. – Ernest Mueller Nov 2 '10 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.