IIS的應用程序池優化方法

IIS的應用程序池優化方法

IIS應用程序池優化方案

服務器常常產生「應用程序池 'DefaultAppPool' 提供服務的進程關閉時間超過了限制。進程 ID 是 '3504'。」的錯誤，致使iis處於假死狀態，經瞭解是IIS應用程序池的設置問題。解決方法以下(紅色字爲標記)：

Internet 信息服務(IIS)管理器－＞應用程序池－＞DefaultAppPool－＞右擊屬性
1、回收
一、回收工做進程（分鐘）：選中，值爲1740  (800)
二、回收工做進程（請求數目）： (不選)（原先設置爲35000）
三、在下列時間回收工做進程：不填  (03:00)
四、消耗太多內存時回收工做進程：全不選。（二、三、4項可能避免了在訪問量高的時候強制回收進程可能引起的服務器響應問題，致使iis假死不響應） (最大虛擬內存350,最大使用的內存200)
2、性能  (都不選)
只選中空閒超時20分鐘。其餘都不選。WEB園最大工做進程數爲1（默認）。注意web園這裏必定要保持默認，若是填寫其餘超過1的數字就會致使一些網站程序的後臺程序打不開或者刷新不停。

原來的請求隊列限制爲4000，如今無限制。 (要選就是10000)
3、運行情況
(啓用PING,默認)

(啓動快速失敗保護的鉤去掉！)
爲了不真的遇到不少錯誤時沒有提示，能夠不關閉，只是把快速保護的保護範圍加大些，例如失敗數50次 時間段5分鐘 則關閉對應的程序。

(啓動時間限制90秒，關閉時間限制180秒。)
「關閉時間限制180秒」是必須的，由於進程關閉的時間，原來爲90秒限制,是默認值，若是進程關閉時間超過90秒，則認爲超時，從而出現：進程關閉時間超過了限制 日誌，因此，適當延長這個時間，能夠避免這種錯誤！

IIS6.0應用程序池回收和工做進程

公司的一個網站程序長時間運行後，速度變慢，從新啓動網站後速度明顯變快，估計是網站程序佔用的內存和CPU資源沒能及時釋放，才須要每隔一段時間重啓網站釋放資源。但手工重啓總不能算解決問題的方法，怎樣才能實現自動管理呢?IIS6.0的應用程序池自動回收功能能夠解決這一問題。

應用程序池是將一個或多個應用程序連接到一個或多個工做進程集合的配置。由於應用程序池中的應用程序與其餘應用程序被工做進程邊界分隔，因此某個應用程序池中的應用程序不會受到其餘應用程序池中應用程序所產生的問題的影響。

爲Web程序配置應用程序池須要如下步驟：1)建立應用程序池，右鍵單擊「應用程序池」，「新建/應用程序池」，命名爲KefuAppPool;2)爲Web程序指定應用程序池，在網站虛擬目錄屬性「應用程序設置」裏面的「應用程序池(N)」裏選擇KefuAppPool;3)應用程序池自動回收方式的設置。回收方式有以下幾種：

a.根據運行時間

系統默認是1740分鐘,也就是29個小時,這個不是很好控制,建議不用。

b.請求數目

這個要看具體的狀況了。若是隻有10個請求，但是有5個都在請求那個比較佔資源的頁面(多是統計年度報表之類)，這個時候就會出現進程當掉的狀況，若是請求有1000個但是一個也沒運行比較佔資源的頁面，這個時候進程確定是很正常的，因此根據請求的數目來決定也不必定符合實際須要。

c.計劃的時間

這個其實很好，不過具體什麼時間回收好呢?一般咱們都是設置在凌晨兩三點鐘，這個時候回收是有必要的，不過針對出現隨時可能出現是高內存佔用並非很適用。

d.內存(虛擬內存或已使用的內存)

這個針對出現內存問題引發的進程當掉實在太合適了，不過設置多大的值比較好是一個很重要的問題，值不能過小了，不然若是訪問量都很大超過這個值的時候也會自動回收，這個就很不必了。必定要多多觀察進程的實際佔用狀況再作決定。

下面重點談談對工做進程回收應用程序池的理解。

默認狀況下，WWW服務創建「重疊回收」，即繼續運行要終止的工做進程，直到啓動新的工做進程後爲止。 在重疊回收方案中，要回收的進程繼續處理請求，同時 WWW 服務建立一個替代工做進程。在中止舊工做進程以前啓動新的工做進程，而後將請求定向到新的進程。此設計能夠防止服務中斷，由於舊進程關閉前仍然保持與 HTTP.sys 的通訊以處理請求。由於可重疊關閉或啓動的關閉超時值是能夠配置的，因此在工做進程仍在處理請求的同時能夠終止該進程(若是它在時間限制內沒有處理完請求的話)。

注意：當 WWW 服務回收某個工做進程時，它並不斷開現有的 TCP/IP 鏈接。HTTP 協議堆棧 (HTTP.sys) 創建並維護 TCP/IP 鏈接。

IIS中的每一個應用程序池由一個「工做進程」進行管理，也就是"W3wp.exe" 進程。若是有多個應用程序池中的程序運行，咱們就能看到多個w3wp.exe。這點能夠在任務管理器中看到，以下圖所示，任務管理器中有兩個w3wp.exe進程，剛好對應兩個有應用程序在運行的應用程序池。

在命令提示符下運行iisapp -a，能夠查看w3wp.exe和哪一個應用程序池關聯。

下圖顯示了手動執行應用程序池KefuAppPool的回收，在回收前，回收中和回收後應用程序池和工做進程狀況。咱們注意到：回收過程當中增長了一個工做進程(PID=3896)，該工做進程(PID=3896)啓動好後，舊的工做進程(PID=5716)才被中止，新工做進程(PID=3896)正式替代舊進程工做，這就很好的防止了應用程序池回收過程當中服務被中斷，保證了程序的連續運行。而其餘兩個應用程序池對應的工做進程 PID都沒用變。該圖很好的展現了應用程序池回收的過程。

 

 

應用程序池這個東西着實讓管理服務器的人頭疼，若是不設置好網站隨時有可能罷工，甚至拖累服務器。所以特意找來此文章供你們參考。

另外說一點,若是網站訪問量不是很大，晚上沒什麼人訪問，能夠嘗試凌晨重啓服務器，這樣能夠提升服務器的速度，爲次日的訪問作準備。
 

IIS 6的核心在於工做進程隔離模式，而應用程序池則是定義工做進程如何進行工做，所以，能夠說應用程序池是整個IIS 6的核心。

和IIS 5中只能使用單個應用程序池不一樣，工做在工做進程隔離模式的IIS 6能夠建立多個應用程序池，不一樣的應用程序池之間是徹底隔離的，某個應用程序池中止服務時不會影響到其餘應用程序池。

在使用應用程序池以前，你應該肯定你所須要的應用程序池數量。可能有不少朋友會認爲，既然不一樣的應用程序池之間是徹底隔離的，那麼我只須要爲每一個Web站點建立一個應用程序池就能夠了。這個辦法在IIS服務器上具備較少的Web站點數量時可使用，可是若是IIS服務器上具備不少Web站點數量，那麼這個辦法就不適用了，由於不一樣的應用程序池在被訪問時都會建立各自的工做進程，當大量的工做進程併發工做時會消耗大量的系統資源和CPU利用率，反而會下降服務器性能。你應該根據Web站點的重要性、隔離性、所運行代碼的安全性和穩定性等來對IIS服務器上所具備的Web站點進行劃分，而後根據狀況來決定所須要的應用程序池數量。對於那些很是重要的Web站點、須要單獨隔離的Web站點、所運行代碼穩定性和安全性並不可靠的Web站點配置爲使用各自獨立的應用程序池，而將其餘普通的Web站點配置爲使用一個公共的應用程序池。

默認狀況下，在安裝IIS時會建立一個默認網站並建立一個名爲DefaultAppPool的應用程序池爲其使用;默認配置下的應用程序池已經能夠很好的進行工做，建議你只有在特別須要時纔對應用程序池進行配置。

配置應用程序池屬性

在IIS管理控制檯中展開應用程序池文件夾，而後右擊對應的應用程序池，點擊屬性，你能夠在應用程序池的屬性中進行如下配置：

回收

在回收標籤，你能夠設置工做進程的回收方式：

 

 

回收工做進程(分鐘)：在工做進程運行多少分鐘後回收工做進程，默認啓用，而且設置爲1740分鐘(29小時);

回收工做進程(請求數目)：在工做進程處理多少 個HTTP請求後終止此工做進程，默認禁用，若是啓用則默認值爲35000;

在下列時間回收工做進程：在指定的時間回收工做進程，默認禁用;如需啓用，勾選後點擊添加按鈕添加回收的時間便可，使用24小時制定義回收的時間;

消耗太多內存時回收工做進程：

最大虛擬內存(兆)：當工做進程使用的虛擬內存達到設置的值時回收工做進程，默認禁用，若是啓用則默認值爲500 M;建議設置爲不超過虛擬內存總數的70%;

最大使用的內存(兆)：當工做進程使用的物理內存達到設置的值時回收工做進程，默認禁用，若是啓用則默認值爲192 M;建議設置爲不超過物理內存總數的60%;

另外須要注意的是，應用程序池具備如下兩種工做進程回收方式，不過這兩種回收方式均不會形成Web服務的中斷：

默認狀況下，應用程序池使用重疊回收方式。在這種方式下，當應用程序池要關閉某個工做進程時，會先建立一個工做進程，直到新的工做進程成功建立後才關閉舊的工做進程;

應用程序池也能夠先關閉舊的工做進程，而後再建立新的工做進程。

若是Web 應用程序不支持多實例運行，那麼你必須配置應用程序池禁止使用重疊回收方式。此配置沒法在IIS管理控制檯中進行修改，只能經過在 metabase.xml中修改對應應用程序池的DisallowOverlappingRotation metabase屬性爲true進行。

性能

在性能標籤你能夠設置工做進程的運行方式：

 

 

在空閒此段時間後關閉工做進程(分鐘)：當工做進程空閒多少分鐘後關閉此工做進程，這下降了空閒工做進程對系統資源和CPU性能的消耗，默認啓用而且設置爲20分鐘;

核心請求隊列限制爲(請求次數)：當HTTP.sys接收到某個客戶端發送的HTTP請求時，若是處理此請求的對應應用程序池的工做進程還處於忙狀態，則HTTP.sys將接收到的請求保存在對應應用程序池的請求隊列中，直到工做進程空閒爲止。此選項即用於設置此應用程序池的請求隊列所能容納的請求數量，默認狀況下每一個應用程序池的請求隊列限制爲保留1000個請求，若是超出則向客戶端返回503錯誤，你能夠根據須要適當進行修改，最大能夠設置爲65535。可是若是設置太大則會消耗大量的系統資源 ，而設置過小會致使客戶端訪問時頻繁出現503錯誤。

啓用CPU監視：監視此應用程序池的CPU使用率，默認未啓用;若是某個應用程序池佔用的CPU利用率過多，那麼能夠經過配置此選項來限制此應用程序池;

最大CPU使用率(百分比)：所設置的應用程序池所能使用的最大CPU使用率;啓用CPU監視時默認值爲100;

刷新CPU使用率(分鐘)：刷新CPU使用率的間隔時間;啓用CPU監視時默認值爲5;

CPU使用率超過最大使用率時執行的操做：當此應用程序池的CPU使用率超過所設置的最大CPU使用率時所進行的操做，啓用CPU監視時默認爲無，此時IIS只是在事件日誌中進行記錄而不進行其餘操做;若是選擇爲關閉，那麼IIS將關閉此應用程序池中的全部工做進程;

Web園：在Web園中你能夠配置此應用程序池所使用的最大工做進程數，默認爲1，最大能夠設置爲4000000; 配置使用多個工做進程能夠提升該應用程序池處理請求的性能，可是在設置爲使用多個工做進程以前，請考慮如下兩點：

每個工做進程都會消耗系統資源和CPU佔用率;太多的工做進程會致使系統資源和CPU利用率的急劇消耗;

每個工做進程都具備本身的狀態數據，若是Web應用程序依賴於工做進程保存狀態數據，那麼可能不支持使用多個工做進程。

運行情況

在運行情況標籤你能夠配置應用程序池監視工做進程的運行情況，

 

 

啓用Ping：默認狀況下應用程序池配置爲每隔30秒Ping工做進程，當工做進程沒有進行響應時，則認爲此工做進程出現故障並默認配置爲關閉此工做進程。你能夠修改Ping的時間間隔，可是太長的Ping間隔可能會致使Web服務的中斷，而過短的Ping間隔又會消耗更多的系統資源和CPU利用率，所以建議你保留默認配置;

啓用快速失敗保護：若是Web應用程序代碼編寫有問題，它可能會致使工做進程持續出現問題。默認狀況下應用程序池配置爲啓用快速失敗保護，當工做進程在配置的時間段(默認爲5分鐘)內發生的失敗次數超過了配置的值(默認爲5次)，則禁用此應用程序池。

啓動時間限制：IIS等待屬於此應用程序池的工做進程啓動的時間，當工做進程啓用時間超出此設置值時，IIS會在事件日誌中進行記錄;

關閉時間限制：當IIS檢測到某個工做進程出現故障時，將此工做進程標記爲關閉，此選項指定了IIS等待工做進程自動關閉的時間限制，若是超出此時間限制後工做進程還沒有關閉，則IIS強行關閉工做進程。

標識

在標識標籤，你能夠配置工做進程所運行的用戶帳戶。在IIS 5或者當IIS 6運行在IIS 5隔離模式時，工做進程運行在本地系統帳戶，而運行在工做進程隔離模式下的IIS 6的工做進程運行在網絡服務帳戶下，這下降了系統被攻擊的可能性。

你能夠配置工做進程運行在預約義的本地系統、本地服務或網絡服務帳戶下，也能夠配置爲使用某個自定義的用戶帳戶。建議使用默認的網絡服務帳戶;不過若是爲了更高的安全性，能夠配置使用自定義的用戶帳戶，不過建議你只是將此自定義用戶加入到IIS_WPG用戶組中，所以IIS_WPG用戶組包含了能夠啓動和運行工做進程的最小權限。

 

 

1)在任務管理器中增長顯示pid字段;2)在命令提示符下運行iisapp -a。注意，第一次運行，會提示沒有js支持，點擊肯定。而後再次運行就能夠了。這樣就能夠看到pid對應的應用程序池。如上圖左側所示，應用程序池 KefuAppPool和PID=3232的w3wp.exe相關聯，應用程序池ReportServer和PID=3572的w3wp.exe相關聯。