IIS停止服務 報錯Connections_Refused

IIS版本6.0  無故停止工作。

        重啓IIS 沒有效果，必須重啓web服務器。出現客戶端無法訪問Web服務器上的站點，錯誤信息提示爲"頁面無法顯示"的情況。登錄服務器檢查後發現IIS並未停止運行，各服務也正常處理，但就是無法訪問站點上的頁面（包括靜態頁面）

首先查看 web服務器的IIS 日誌文檔，位置默認在C:\WINDOWS\system32\LogFiles\ 下
這個目錄下都是IIS的日誌，其中 HTTPERR 文件夾中是IIS的報錯記錄

打開HTTPERR 文件夾中出錯日期的文檔，例如 httperr7.log，顯示

2016-02-18 05:54:22 - - - - - - - - - 1_Connections_Refused -

2016-02-18 05:59:22 - - - - - - - - - 1_Connections_Refused -

2016-02-18 06:02:07 - - - - - - - - - 5_Connections_Refused -

2016-02-18 06:03:37 - - - - - - - - - 2_Connections_Refused -

2016-02-18 06:03:42 - - - - - - - - - 2_Connections_Refused -

2016-02-18 06:04:22 - - - - - - - - - 1_Connections_Refused -

2016-02-18 06:08:12 - - - - - - - - - 4_Connections_Refused -

2016-02-18 06:08:17 - - - - - - - - - 1_Connections_Refused -

2016-02-18 06:08:47 - - - - - - - - - 4_Connections_Refused -

2016-02-18 06:09:22 - - - - - - - - - 1_Connections_Refused -

2016-02-18 06:09:47 - - - - - - - - - 1_Connections_Refused -

解決方法：

微軟的官方解決方案，http://support.microsoft.com/kb/934878/zh-cn解決方法如下： 
1.進入註冊表，進入具體項：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters 
2.新建dword值，輸入名稱“EnableAggressiveMemoryUsage” 
3.修改值爲1. 
4.開始-運行，輸入CMD。進入CMD窗口。 
5.執行：net stop http /y 
6.執行：iisreset /restart 
IIS問題得到解決。

備註：
經過我們解決問題發現時因爲網站所在的應用程序池中請求隊列限制，限制在1000，根據自己的網站流量，果斷設置爲 5000-10000就解決了，默認的1000確實有點少了

 

分析：

        這個問題是在默認情況下，如果可用的非分頁緩衝池內存不足 20MB，Http.sys 服務將停止接收新連接，就會出現上述問題。這也就解釋了爲什麼重啓IIS沒用，只能通過重啓Web服務器釋放內存資源來解決。

        要分析這個問題，首先得了解下Windows系統中的核心內存概念：核心內存是Windows分配給系統內核或驅動所需的內存空間，分頁內存是虛擬內存，也就是這一部分內存可以置換到硬盤中，但是，非（未）分頁內存是不能置換到硬盤的，只能保存在物理內存中，常用於一些軟件或是系統的驅動程序使用。如果未分頁內存無限增大，到達一個閥值，就會造成系統問題。在32位的Windows上，這個閥值最高不能超過256MB，否則操作系統會變得非常不穩定。
    打開自己系統的任務管理器，在"性能"項中，可以看到：

 

如上圖所示，這就是我本機當前時刻所使用的分頁和未分頁內存數，這個數字很正常。

     我們再來看下最近這臺有問題的機器連續2天，2次出現故障時的內存使用數，未分頁內存已經不知不覺暴漲到230多M了

         好了，廢話不多說，這個時候就需要用到Poolmon這個核心內存泄漏檢測工具了。通過這個工具，我們來看看Web服務器上到底是哪些軟件或者程序造成內存泄露，從而導致未分頁內存數不足的。
         Poolmon是類似於Dos 的命令行執行程序，基本上完成檢測的操作我們只需要2個指令： P-排序標籤列表通過分頁，非分頁，混合等3種模式；B-對標籤排序最大字節使用情況。
        如下圖所示：顯示的就是操作系統中所有佔用非分頁內存項，並按字節大小降序排列。我們找出排在前面，並且字節數不斷增加的tag項，根據Tag來定位進程和驅動文件。比如我們想看下目前佔用90M非分頁內存的Thre項，在Dos中輸入: 
    findstr /s /m /l "Thre" c:\windows\system32\drivers\*.sys

        如上圖所示，我們看到是系統驅動和殺毒驅動佔用了Thre。這臺機器上次中過毒，所以後來下了瑞星和360衛士來排毒。瑞星是出了名的耗未分頁內存大戶，360衛士本身也已經被病毒感染，所以我基本鎖定了這2款軟件，先卸載，然後重啓服務器，重新下載360衛士和360殺毒再次排毒之後觀察服務器運行情況和內存消耗情況。從上次重啓到目前爲止，運行十多天，未分頁內存總消耗保持在50M以內，雖有小許增長，但還算正常。到此，根據上面的分析， 我們就可以定位出導致IIS故障的真正問題所在了。這種問題，很大部分是因爲殺毒軟件程序或者一些系統驅動導致的。

        這裏說的很大部分原因是因爲殺毒軟件程序或者一些系統驅動導致的非分頁內存不足，是因爲非分頁內存一般是內核程序或驅動程序在請求。這種資源非常寶貴，如果程序處理不當的話，也會導致上述情況，比如一個Socket只接受連接，但因爲某些原因沒有讀取數據，然後客戶端連接上之後一直髮送數據，在這種極端的情況下未分頁內存也很快就會被佔滿。