Recycling Worker Processes
Applies To: Windows Server 2003, Windows Server 2003 with SP1
If an application contains code that causes problems, and you cannot easily rewrite the code, it might be useful to limit the extent of the problems by periodically recycling the worker process that services the application. Worker process recycling is the replacing of the instance of the application in memory. IIS 6.0 can automatically recycle worker processes by restarting the worker process, or worker processes, that are assigned to an application pool. This helps keep problematic applications running smoothly, and minimizes problems such as memory leaks.
You can trigger the recycling of the worker processes assigned to an application pool by using worker process recycling methods that are based on elapsed time, the number of Hypertext Transfer Protocol (HTTP) requests, a set time of day, and two kinds of memory consumption, in addition to recycling on demand. Table 4.1 lists and describes the worker process recycling methods and when to use each.
Table 4.1 Worker Process Recycling Methods
| Method | Description | Usage |
|---|---|---|
Elapsed time |
Recycles the worker process based on a timeframe, in minutes, that is specified by the administrator. |
Use this method when applications have problems running for extended time periods. |
Number of requests |
Recycles the worker process when the number of HTTP requests exceeds a threshold that is specified by the administrator. |
Use this method when applications are failing based on the number of requests they receive. |
Scheduled times |
Recycles the worker process at specified times within a 24-hour period. |
Use this method when conditions are similar to the conditions for elapsed time. |
Virtual memory |
Recycles the worker process when the worker process virtual memory reaches a threshold that is specified by the administrator. |
Use this method when the memory heap becomes highly fragmented, which occurs when applications reserve memory multiple times. This is indicated by a steady increase in virtual memory. |
Used memory |
Recycles the worker process when the memory that is used by the W3wp.exe process reaches a threshold that is specified by the administrator. |
Use this method when some of your applications have memory leaks. |
On demand |
Recycles the worker process when an administrator uses Microsoft Management Console (MMC) or a script to request the recycling of an entire application pool. |
Use this method when an application pool is causing problems while the other sites are up and running. Consider recycling the application pool, as opposed to resetting the entire WWW service. |
By setting the values for worker process recycling methods, you can schedule recycling events to manage application problems in a timely manner. Table 4.2 lists recommendations for adjusting the values of worker process recycling methods.
Table 4.2 Recommended Settings for Values of Worker Process Recycling Methods
| Recycling Method | Recommended Setting |
|---|---|
Elapsed time |
Set this value to be less than the length of time elapsed before the worker process fails. |
Number of requests |
Set this value to be less than the number of requests processed before the application fails. |
Scheduled times |
Set this value to be at intervals that are frequent enough to prevent application failure. |
Virtual memory |
Initially, set this value to be less than 70 percent of available virtual memory. Then monitor the memory usage of the worker process, and adjust the setting if memory usage continues to increase. Calculate this value in megabytes. |
Used memory |
Set this value to be less than 60 percent of available physical memory. Calculate this value in megabytes. |
On demand |
Consider using one of the automated methods for recycling instead, because on-demand recycling is typically performed in response to a failure. |
Recycling and Maintaining State
If you have an application pool with applications that depend on state data, you must decide whether or not to recycle the worker processes that are assigned to that application pool. When you recycle a worker process, the state data for applications that is maintained in process is lost. In this case, do not use recycling.
One alternative to increasing application availability by recycling worker processes is to maintain state data external to the worker process, such as in a database. However, moving data to an external database to allow recycling can affect server performance in the following two ways:
Performance is reduced because of the added data management that is needed to move the data between the application and the database.
Recycling flushes any in-process data caches, so the caches need to be rebuilt.
ASP.NET gives you the option of persisting session state using a session state service or a SQL database. For more information on deploying ASP.NET applications, see Deploying ASP.NET Applications in IIS 6.0.
Global Locks and Overlapped Recycling
Using global locks, configuring files for exclusive read, and other methods of exclusive resource ownership prevent the use of overlapped recycling, or the loading of an application in two application pools simultaneously. Exclusive ownership requires the use of non-overlapped recycling and the routing of all requests for that application to the same application pool. Also, you can run only one worker process for that application pool, which means that exclusive ownership does not work in a Web garden. One way to work around this is to write multithreaded applications, or use shared reads, which might eliminate the need for exclusively owned resources.