Analysis on collection settings of IIS6.0 application pool

The problem is as follows:
1. Web page display

The Web application you are attempting to access on this Web server is currently unavailable. Please click "refresh" in the Web browser to try your request again.
Administrator considerations:
You can find the error details for the specific cause of request failure in the system event log of the Web server. Check this log item to find out the cause of this error.

2. windows event viewer-Application Log

The state server has closed an expired TCP/IP connection. The IP address of the client is 127.0.0.1. The expired Read operation began at 05/21/2007 20:12:04.

The solution is simple. Just recycle the IIS application pool corresponding to the program.

But why? Why is it okay to recycle it? What does recycling do?
Cause
I searched the internet and found several problems, of course, there are other reasons

1). Framework problems, such as version 1.0 and 2.0
22.16aspnet_wp.exe
3) Security Update Program (KB886903)

Unfortunately, the problems on our servers are not caused by the above issues. After my analysis, I thought it was a bad program, which occupied a lot of resources and finally caused Memory leakage, this causes the IIS process to crash. Unfortunately, I can't change the program. It's all written by others, and it won't be changed. However, it is impossible for me to log on to the remote server and recycle it once every time this problem occurs.

There are several automatic recovery methods, and I don't know which one is more suitable. In addition, the recycle worker will clear the Session stored in the memory, causing the user to log on again, so the fewer automatic recovery, the better, to ensure that other users will not log on again because one of the users uses the bad program.

If the status server is used or the program that saves the Session to the database is automatically recycled, the operation will not be affected, and the request will not be interrupted, I just changed a working process and continued to work for the client. The client could not feel it. It was really a mistake to save the Session to the database for convenience!

1. Based on the running time
The default value is 1740 minutes, that is, 29 hours. This is not a good control. We recommend that you remove this check box.

2. Number of requests
This depends on the specific situation. If there are only 10 requests, but five of them are requesting the page that accounts for the resources (probably the annual report statistics), the process may crash at this time, if there are 1000 requests but one page does not run, the process is certainly normal at this time, so the decision based on the number of requests does not meet the actual needs.

3. Scheduled time
This is actually good, But what time should it be recycled? We usually set the collection before and after work, which is necessary at this time, but it is not very suitable for high memory usage that may occur at any time.

4. Memory (virtual memory or used memory)
This is too suitable for the process caused by memory problems, but it is very important to set the maximum value, I decided based on the actual usage of the process each time a problem occurs. Our server memory is 2 GB, and some other services usually occupy more than 600 mb. I found that every time the process reaches more than 1 GB, therefore, when the maximum memory usage is set to MB, it will be automatically recycled. After the setting, no problem will occur. To check the process usage, simply use the windows Task Manager. The value cannot be too small. Otherwise, if the access volume is too large to exceed this value, it will be automatically reclaimed, which is unnecessary. You must observe the actual usage of the process before making a decision.
If the LogEventOnRecycle attribute of the IIsApplicationPools node is configured in the IIS configuration file, the IIS log file records the relevant information according to the value of the LogEventOnRecycle attribute during each collection, this is also an important reference for setting automatic recovery. However, because this log file can only be viewed for a few hours ago, the current record will only be written in a few hours, so it seems inconvenient, depressed!

Currently, the previous problem is solved based on the maximum occupied memory. I also found some new problems and I don't know how to set them elsewhere. Is there a better way? I hope that the author of this article can give some valuable comments and share their experiences.

The IIS configuration file is in the windows Installation Directory (C:/WINDOWS/system32/inetsrv/MetaBase. xml). To directly modify the configuration file, you need to stop the IIS service. Remember to back up the file before modification.

Some configuration information, write fun

Copy codeThe Code is as follows: <IIsApplicationPool Location = "/LM/W3SVC/AppPools/DefaultAppPool"
AppPoolAutoStart = "TRUE"
PeriodicRestartMemory = "2000" // maximum virtual memory MB
PeriodicRestartPrivateMemory = "1000" // maximum memory usage MB
PeriodicRestartRequests = "1000" // number of requests
PeriodicRestartSchedule = "// automatic recovery time
12: 00
20: 00"
>
</IIsApplicationPool>

The following is an excerpt from the help provided by IIS.

How to recycle work processes
Based on the collection configuration method of the application pool, the World Wide Web Publishing Service (WWW Service) can use two methods to recycle allocated working processes:

• By default, the WWW Service creates an "Overlap Recycle", that is, it continues to run the work process to be terminated until a new work process is started.
• Alternatively, the WWW Service can terminate a working process and start a new working process (if the workload permits this operation ).

Note that when the WWW Service recycles a working process, it does not disconnect the existing TCP/IP connection. The HTTP protocol stack (HTTP. sys) establishes and maintains TCP/IP connections.

In the overlapping recycling scheme, the process to be recycled continues to process requests, and the WWW Service creates an alternative working process. Start a new working process before stopping the old working process, and then direct the request to the new process. This design prevents service interruptions because the old process still maintains communication with HTTP. sys before it is closed to process requests. Because the timeout values for overlapping shutdown or startup shutdown can be configured, therefore, the worker can terminate the process while processing the request (if it has not completed the request within the time limit ).

When you configure an application pool to recycle working processes based on the running time, You can reclaim all working processes within the set running time, but not all of them at the same time. Applications can be recycled at different time periods within the set time to reduce the number of client request service interruptions.

Similarly, when you configure an application pool to reclaim an application based on the number of requests processed, You can reclaim the application at intervals to share the system overhead related to the collection of work processes.

When to recycle a Workflow
The following general guidelines should be taken into account when deciding whether to start a workflow recycle. The best solution is to fix the application that causes the fault. However, it is not always possible to use reencoding, especially when other running application code cannot be modified.

Recycling is considered in the following cases:

• Failed applications under your control on the Web server.
• An uncertain or intermittent fault occurs.
• You suspect that the application may leak memory due to performance monitoring.
• A temporary reset solution has been implemented previously, for example, planned executionIISResetCommand line utility.

Under the following circumstances, recycle may not be required at all:

• The website you host only contains static content, and does not contain custom Internet Server API (ISAPI) applications.
• The application you are using has been fully tested, and there will be no memory or resource allocation problems.

To effectively use recycling, carefully check the standards on which recycling is based (as shown in the following table ).

Conditions for recycling	Description	Time used
ISAPI request	Reclaim the Workflow Based on the ISAPI request in the application pool.	ISAPI extensions can declare themselves as unhealthy.
Running time	The process is recycled based on the time (in minutes) specified by the user.	Failed applications run for too long.
Number of requests	Reclaim a workflow when a Hypertext Transfer Protocol (HTTP) request exceeds a specific threshold.	The application fails based on the number of requests received by the application.
Scheduled time	Reclaim data within 24 hours.	The condition is similar to the running time condition.
Virtual Memory (Reserved memory and used memory)	The worker process is recycled when the virtual memory of the worker process reaches a specific threshold.	Too many memory stack fragments (this is because the application retains the memory for multiple times ). The symptom is that the virtual memory continues to increase.
Used memory	When the memory used by the W3wp.exe process reaches a specific threshold, the worker process is recycled.	Memory leakage occurs in some applications.
As needed	When the IIS administrator can use Microsoft? The Management Console (MMC) or script starts to recycle the entire application pool.	When other sites start and run, there is a pool of applications that cause a fault. Consider revoking this application without resetting the entire WWW Service.