Recently I had chance to look into IIS's capability to auto recycle app pool. Because one of our web app was hogging the whole server claiming all the memory it can get when it working at its peak.
When hosting applications on IIS (Internet Information Services), managing application pool recycling is crucial for ensuring stability and performance not only on the target app, but for whole server. Recycling helps refresh the application environment by periodically restarting the worker process to prevent memory leaks, releasing un-wanted memory, resource locking and unexpected issues.
Recycling Settings in IIS App Pools
Recycling settings are per App Pool. There fore you can configure each pool differently. These settings can be found in Advanced Setting dialog. Right click on the desired Application Pool and go to "Advanced Settings" dialog.
There are lot of "Advanced Settings" therefore, you might have to scroll down to see these settings, they are at the right below the dialog.
"Disable overlapping recycle", "Disabling Recycling for Configuration Changes" (blog done for this), "Generate Recycle Event Log Entry" are settings which are relate to recycling but not something allow us to control recycling times. So we skip them for bit.
1. Regular Time Interval (Fixed Interval Recycling)
Setting Name: Regular Time Interval (in Minutes)
Default: 0 - means application pool will not recycle regular time intervals
Description: Automatically recycles the worker process after a specified time interval.
Use Case: Useful for applications that need periodic refreshing to prevent performance degradation. However, setting this too frequently can disrupt user sessions. For example you can set your application pool to restart every 12 hours (720 minute), when you know these 12 hour intervals are not its peak times.
2. Specific Time(s) (Scheduled Recycling)
Setting Name: Specific Times
Description: Allows recycling at predefined times during the day.
- Use Case: Ideal for scheduled maintenance windows. For example, in above screen shot we recycle application pool at 00:05 mid night, then 3:05AM (which is probably after maintenance job), then 6.30AM (just before users try to access), 12.45PM (mid day when traffic is low when every one at lunch), 5.30PM (when users logging off), 7PM (before we kick off maintenance tasks).
3. Memory-Based Recycling
a) Private Memory Limit
Setting Name: Private Memory Limit (KB)
Description: Recycles the worker process when its private memory consumption exceeds a specified threshold.
Use Case: Helps prevent excessive memory usage due to memory leaks in applications. For example, if an app is expected to use a maximum of 2 GB, setting a limit slightly above (e.g., 2.5 GB) ensures it gets recycled before causing server slowdowns.
b) Virtual Memory Limit
Setting Name: Virtual Memory Limit (KB)
Description: Recycles the worker process when its virtual memory usage exceeds a specified limit.
Use Case: Less commonly used but can help control applications with excessive virtual memory allocations. Similar to private memory limit, but include shared memory space as well.
4. Request-Based Recycling
a) Request Limit Recycling
Setting Name: Request Limit
Description: Recycles the worker process after processing a specified number of requests.
Use Case: Useful for high-traffic applications where a certain number of requests may cause the application to degrade. For example, if an API handles millions of requests daily, recycling it after every 500,000 requests can help maintain performance.
No comments:
Post a Comment