Of course, this could have been in .NET 1.0 but the article in MSDN library is from February 2003. But I'm jumping ahead of myself.
Check, a coworker (and VB.NET lover - I've tried converting him to C# :) whose application has seen more users than all of mine by an order of magnitude... brought an issue to my attention about 6+ mos ago. Apparently, the aspnet worker process was eating memory for lunch and never giving it up. Once it reached about 750MB's it would peg the CPU and refuse all requests. The quick-fix of course was to kill the worker process, and it would restart with only 3MB of memory. Definitely inelegant especially since all session variables are blown away.
When he brought this to my attention, my knee-jerk reaction was to point out something I had learned about IIS6 - namely that IIS6 offers the capability of restarting the worker process on a defined schedule. However, the bigger question was why was this happening in the first place? Some sort of memory leak? Did the garbage collector suddenly give up?
Well here it is 6mos later. Check wrote a VB.NET console app a few days ago to kill the worker process. However, his concern for support of IIS6 led him to find that the aspnet_wp.exe process name has changed. Which led to further research... which led to some highly interesting <processModel> configuration attributes (C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config). According to the machine.config:
processModel Attributes:
- enable="[true|false]" - Enable processModel
- timeout="[Infinite | HH:MM:SS] - Total life of process, once expired process is shutdown and a new process is created
- idleTimeout="[Infinite | HH:MM:SS]" - Total idle life of process, once expired process is automatically shutdown
- shutdownTimeout="[Infinite | HH:MM:SS]" - Time process is given to shutdown gracefully before being killed
- requestLimit="[Infinite | number]" - Total number of requests to serve before process is shutdown
- requestQueueLimit="[Infinite | number]" - Number of queued requests allowed before process is shutdown
- restartQueueLimit="[Infinite | number]" - Number of requests kept in queue while process is restarting
- memoryLimit="[number]" - Represents percentage of physical memory process is allowed to use before process is recycled
- responseDeadlockInterval="[Infinite | HH:MM:SS]" - For deadlock detection, timeout for responses when there are executing requests.
When ASP.NET is running under IIS 6 in native mode, the IIS 6 process model is used and settings in this section are ignored. Please use the IIS administrative UI to configure things like process identity and cycling for the IIS worker process for the desired application.
Of course the important ones to note are: idleTimeout (which allows you to shutdown the worker process when no one has hit your app in a while), memoryLimit (which lets you determine how far the worker process will get before thrashing like mad) and responseDeadlockInterval (which allows you to monitor the worker process and kill it if it starts thrashing; his was set to 30minutes - a big contributor). I probably saw this on my cert test, but I forget. Either way useful info. Now the questions are: Why does the worker process start thrashing once it reaches it's memory limit? Is the garbage collector coded that badly?
posted @ Monday, April 18, 2005 5:04 PM