In fact, this article has been written for a long time, but it has not been reproduced at that time, or it will be temporarily handled because of the importance of the business and the pressure of complaints. In the past few days, the Web server in a city has encountered this problem for many times, and I just used this case to make a final conclusion.
In the past few months, an important Web server (Windows Server2003 + IIS6.0) encountered a problem where the client could not access the site on the Web server and the error message was "Page unavailable. After logging on to the server, you can find that IIS is not running and services are working properly. However, you cannot access the pages on the site (including static pages ). In fact, this problem often occurs before. Basically, the solution is to restart the Web server to solve the problem. There is no specific conclusion or basis for such a solution, most of them are caused by personal experience. Therefore, this solution can only relieve the pressure on complaints and does not fundamentally solve the problem.
Now, we will discuss this issue in depth, find out the root cause of the problem, and strive to achieve a permanent cure.
First, it must be the analysis of IIS logs on the problematic server. I found that during the time when the site was inaccessible, a large number of "Connections_Refused" errors were recorded in the httperr logs.
By default, if the available non-Paging buffer pool memory is less than 20 MB, the Http. sys service will stop receiving new connections. This explains why it is useless to restart IIS. You can only restart the Web server to release memory resources.
There are also official Microsoft solutions on the Internet:
1. Go to the Registry and find the following items:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ HTTP \ Parameters;
2. Create a Dword Value and enter the name "EnableAggressiveMemoryUsage ";
3. Change the value to 1;
4. Restart the HTTP service:
Execute in DOS separately
Net stop http/y
Iisreset/restart
I configured the server according to the preceding instructions, but I cannot verify the effect. I can only observe the subsequent running status of the server first. This method is more advanced than restarting the Web server. At least this method is more clear about the cause of the problem and is closer to the truth. What is the real cause of the problem? What makes the non-Paging buffer pool memory continuously increase to less than 20 mb?
To analyze this problem, first understand the core memory concept in Windows: the core memory is the memory space required by Windows to allocate to the system kernel or driver, and the paging memory is virtual memory, that is, this part of memory can be replaced with the hard disk. However, non-Paging memory cannot be replaced with the hard disk and can only be stored in the physical memory, it is often used in some software or system drivers. If the non-Paging memory increases infinitely, reaching a threshold will cause system problems. On 32-bit Windows, the threshold value cannot exceed 256 MB. Otherwise, the operating system becomes unstable.
Open the task manager of your system. In the "performance" item, you can see:
As shown in, this is the number of pages and non-Paging memory used by my local machine at the current time. This number is normal.
Let's take a look at the memory usage of the faulty machine for two consecutive days when two failures occurred. The non-Paging memory has jumped to over 230 MB without knowing it.
Well, you don't need to talk about it. In this case, you need to use the core memory leak detection tool Poolmon. Using this tool, we can see which software or programs on the Web server cause memory leakage, resulting in insufficient non-Paging memory. Poolmon is a Dos-like command line execution program. Basically, to complete the detection, we only need two Commands: P-Sort tag list through paging, non-Paging, hybrid, and other three modes; b-maximum byte usage for sorting tags. As shown in: all non-Paging memory items in the operating system are displayed and sorted in descending order by byte size. We can find the tag items that are at the top and the number of bytes is increasing, and locate the process and driver files based on the Tag. For example, if you want to view the Thre items that currently occupy 90 m of non-Paging memory, input the following in Dos:
Findstr/s/m/l "Thre" c: \ windows \ system32 \ drivers \ *. sys
As shown in, we can see that the system drive and anti-virus drive occupy Thre. This machine was poisoned last time, so we went down with rising and 360 guard for detoxification. Rising is a famous memory-consuming, non-Paging user, and the 360 Guard itself has been infected with viruses. Therefore, I basically locked the two software, uninstalled it first, and then restarted the server, download 360 guard and 360 anti-virus again and observe the server running status and memory consumption. Since the last restart till now, the total consumption of non-Paging memory has remained below 50 MB for more than ten days. Although it has increased slightly, it is still normal. At this point, based on the above analysis, we can locate the real problem that causes the IIS fault. Most of these problems are caused by anti-virus software programs or system drivers.
Most of the reason is that the non-Paging memory is insufficient due to anti-virus software programs or some system drivers, because the non-Paging memory is generally requested by the kernel program or driver. This kind of resource is very valuable. If the program is improperly processed, it will also lead to the above situation. For example, a Socket only accepts connections, but for some reason it does not read data, then, the client sends data after connection. In this extreme case, the non-Paging memory will soon be full.