如何回收IIS應用程序池?

如何回收IIS應用程序池?  

如何回收IIS應用程序池? 11小時前

　　把程序對應的IIS應用程序池回收一下就行了。

　　但是爲何會出現這個緣由呢？還有爲何回收一下就行了呢？回收作了些什麼？

　　出現的緣由

　　在網上搜索了一翻，發現主要是一下幾個問題，固然還有其餘緣由

　　1）.Framework的問題，例如1.0和2.0版本

　　2）aspnet_wp.exe 問題

　　3）安全更新程序 (KB886903)

　　惋惜咱們服務器出現的問題都不是以上幾點引發的，通過個人分析認爲是寫的很爛很爛的程序佔用了大量的資源最後致使內存泄漏，致使IIS的進程當掉了。惋惜了程序我是沒辦法改，都是別人寫的，也不會改。不過我不可能每次出現這個問題就登錄到遠程服務器上去回收一次吧，因此只有讓他自動回收了。

　　自動回收有好幾種方式，也不知道那一種比較適合，並且回收工做進程是會把保存在內存裏的Session清空，形成用戶須要從新登錄的問題，因此自動回收要越少越好，以保證不會由於其中的一個用戶使用了那個很爛的程式致使其餘的用戶都要從新登錄。

　　若是用了狀態服務器或者是把Session保存到了數據庫中去的程序自動回收後確定是沒有任何影響的，請求也不會中斷仍是同樣繼續運行，只是換了個工做進程繼續爲客戶端工做，客戶端是感受不到的，當初沒有爲了方便沒有把Session保存到數據庫真是失策！

　　根據運行時間

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

　　請求數目

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

　　計劃的時間

　　這個其實很好，不過具體什麼時間回收好呢？一般咱們都是設置上班前和下班後回收，這個時候回收是有必要的，不過針對出現隨時可能出現是高內存佔用並非很適用。

　　內存（虛擬內存或已使用的內存）

　　這個針對出現內存問題引發的進程當掉實在太合適了，不過設置多大的值比較好是一個很重要的問題，我是根據每次出現問題時進程是實際佔用狀況決定的。咱們的服務器內存是2G，一般其餘的一些服務會佔用掉600多M，我發現有每次進程都是到1G多的時候當掉，因此設置了最大使用內存爲1000M的時候自動回收，設置後一直都沒出現問題了。要查看進程的佔用直接用windows任務管理器就好，值不能過小了，不然若是訪問量都很大超過這個值的時候也會自動回收，這個就很不必了。必定要多多觀察進程的實際佔用狀況再作決定。

　　在IIS的配置文件裏面若是配置了IIsApplicationPools節點的LogEventOnRecycle屬性，每次回收的時候IIS的日誌文件會根據LogEventOnRecycle屬性的值紀錄下相關的信息，也個也是設置自動回收時的一個重要參考，不過因爲這個日誌文件只能看幾個小時之前的紀錄，當前的紀錄要幾個小時後才寫進去，因此看起來不方便，鬱悶！

　　如今暫時根據最大佔用內存自動收回之前的問題是解決了，暫時也發現什麼新問題了，也不知道其餘地方都是怎麼設置的，是否是還有更好的方法呢？但願到了這篇文章的人能提點寶貴意見，你們一塊兒交流一下經驗。

　　IIS的配置文件在windows的安裝目錄下（C:\WINDOWS\system32\inetsrv\MetaBase.xml），直接修改配置文件須要中止IIS服務，修改前記得備份。

　　部分配置信息，寫的好玩的

　　<IIsApplicationPool Location ="/LM/W3SVC/AppPools/DefaultAppPool"

　　AppPoolAutoStart="TRUE"

　　PeriodicRestartMemory="2000" //最大虛擬內存MB

　　PeriodicRestartPrivateMemory="1000" //最大佔用內存MB

　　PeriodicRestartRequests="1000" //請求數

　　PeriodicRestartSchedule="07:50 //自動回收時間

　　12:00

　　20:00"

　　>

　　</IIsApplicationPool>

　　如下是摘錄IIS自帶的幫助。

　　工做進程回收如何工做

　　根據應用程序池回收的配置方式，萬維網發佈服務（WWW 服務）可使用兩種方法來回收已分配的工做進程：

　　默認狀況下，WWW 服務創建「重疊回收」，即繼續運行要終止的工做進程，直到啓動新的工做進程後爲止。

　　或者，WWW 服務能夠終止一個工做進程，而後啓動一個新的工做進程（若是工做負荷容許執行此操做的話）。

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

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

　　在配置應用程序池以基於運行時間來回收工做進程時，能夠在設置的運行時間內回收全部的工做進程，但不能同時回收全部這些工做進程。能夠在設置的時間內的不一樣時段進行回收應用程序，以減小客戶端請求服務的中斷次數。

　　相似地，在配置應用程序池以基於處理請求的數目來回收應用程序時，能夠每隔一段時間回收一次以分擔與工做進程回收有關的系統開銷。

　　什麼時候使用工做進程回收

　　在決定是否啓動工做進程回收時，應考慮如下常規指南。最佳的解決方案是修復引發故障的應用程序。可是，並不是總能使用從新編碼，尤爲是運行的其餘應用程序代碼沒法修改時。

　　在如下狀況下考慮使用回收：

　　沒法修復 Web 服務器上您所主控的有故障的應用程序。

　　遇到不能肯定的或間斷性的故障。

　　您懷疑應用程序因爲性能監視的緣由而泄漏內存。

　　先前已實施了臨時性的重置解決方案，例如，計劃執行 IISReset 命令行實用工具。

　　在如下狀況下，可能根本不須要使用回收：

　　您所主控的網站只包含靜態內容，而且不包含自定義 Internet 服務器 API (ISAPI) 應用程序。

　　您所主控的應用程序已通過徹底測試，而且不會出現內存或資源分配問題。

　　要有效地使用回收，請仔細檢查回收所依據的標準（以下表中所示）。

　　回收依據的條件 描述 使用時間

　　ISAPI 請求 根據應用程序池中 ISAPI 的請求回收工做進程。 ISAPI 擴展能夠將其自身聲明爲運行情況差。

　　運行時間 根據用戶指定的時間（分鐘）回收工做進程。 存在故障的應用程序的運行時間過長。

　　請求數目 當超文本傳輸協議 (HTTP) 請求超出某個特定閾值時回收工做進程。 根據應用程序接收到的請求數目，應用程序出現故障。

　　計劃的時間 在 24 小時內的指定時間進行回收。 條件與運行時間的條件相似。

　　虛擬內存（保留的內存加上已使用的內存） 當工做進程虛擬內存達到某個特定閾值時回收該工做進程。 內存堆棧碎片過多（這是因爲應用程序保留屢次內存形成的）。症狀是虛擬內存持續增長。

　　已使用的內存 當 W3wp.exe 進程使用的內存達到某個特定閾值時回收工做進程。 某些應用程序出現內存泄漏。

　　根據須要 當 IIS 管理員可使用 Microsoft&reg; 管理控制檯 (MMC) 或腳本控制整個應用程序池的回收時開始回收。 在其餘站點啓動並運行時，有一個引發故障的應用程序池。請考慮回收該應用程序，而無需重置整個 WWW 服務。

　　系統中iis(微軟的WEB服務器平臺)日誌：

　　　　應用程序:ISAPI ’C:\WINDOWS\system32\inetsrv\asp.dll’ 報告它自身有問題，緣由以下: ’ASP 不正常，由於執行請求的 100% 被掛起，並且請求隊列已經使用了 0%。’。

　　　　關於server 2003+iis(微軟的WEB服務器平臺)6 出現 ’ASP 不正常，由於執行請求的 100% 被掛起

　　現象以下:

　　　　站點沒法打開,或者打開很慢.HTML能夠打開.從新啓動或者回收應用程序池可恢復.但過一段時間又會出現

　　日誌裏會有:

　　　　ISAPI ’C:\WINDOWS\system32\inetsrv\asp.dll’ reported itself as unhealthy for the following reason: ’ASP unhealthy because 100% of executing requests are hung and 6% of the request queue is full.’.

　　或者:

　　　　ISAPI ’C:\WINDOWS\system32\inetsrv\asp.dll’ 報告它自身有問題，緣由以下: ’ASP 不正常，由於執行請求的 100% 被掛起，並且請求隊列已經使用了 0%。’。

　　解決方法:

　　　　1.asp是否正確映射到’C:\WINDOWS\system32\inetsrv\asp.dll’

　　　　2.通常來說,是因爲在同屬iis(微軟的WEB服務器平臺)的應用程序池出現了某個站ASP代碼錯誤所致,使得內存耗盡,檢查代碼自己的問題.能夠隔離到單獨應用程序池調試

　　　　三、減小應用程序池回收時間。默認爲：1740。。可設爲120（每2小時）

　　iis(微軟的WEB服務器平臺)假死的緣由：

　　　　打開iis(微軟的WEB服務器平臺) 你就會看到應用程序池，默認只有一個應用程序池，查看應用程序池的屬性，會發現他的回收時間，默認多達，1740分鐘，就是說，須要在1740分鐘後纔回收此應用程序池，若是在這個時間內，達到請求的最高限制，那麼就會出現ASP假死的狀況，這個就是大型網站出現假死的狀況，反而，小型網站確不會出現這樣的狀況，由於他請求少，流量少，還沒達到限制數量。固然要看你的服務器上網站數目而定。

　　如下是解決方法:

　　　　資料一

　　　　單個網站解決方法:

　　　　把應用程序池回收時間縮短到300-600分鐘，其間回收過程當中，須要佔用一點CPU資源，沒辦法，爲了穩定性，再把回收時間設爲凌晨5點。

　　多網站解決方法：

　　　　視服務器網站的多少，新建多個應用程序池，把每一個池回收時間縮小到300分鐘，而後再分配每一個池10個網站左右(這個分配是要求你的網站訪問量所定)若是某個網站，訪問量大，就單獨給他一個程序池，可是這樣作的後果就是須要大內存，一個池如今佔用我120M內存左右，反正內存大，不要緊，

　　　　那麼多網站如何分配應用程序池，打開iis(微軟的WEB服務器平臺)--查看你要分配的網站屬性，查看主目錄--在下面你就會看到應用程序池了，分配一個就好了。

　　資料二

　　　　你們在使用iis(微軟的WEB服務器平臺)6時..若是裝了動網論壇.確定有出現過iis(微軟的WEB服務器平臺)6假死現像..就是asp網頁打開慢..可是iis(微軟的WEB服務器平臺)倒是正常的..靜態網頁打開速度同樣..這時候..我一直是重啓的方法..查了官方的資料結果沒有...據官方資料說..win2003很快就要打這個補丁了..是iis(微軟的WEB服務器平臺)6對access(小型網站之最愛)驅動支持不理像..也算是一個bug吧..因爲個人服務器虛擬主機多..並且大多支持asp..若是一旦假死就沒法運行..在多方面的資料查找下..找到了一個比較簡單的方法..具體我測試是經過了..iis(微軟的WEB服務器平臺)6自帶數據應用程序池..如今就利用他來解決假死..

　　　　首先把bbs設一個單獨的目錄..而後點擊應用程序池..新建應用程序池.輸入應用程序池id..

　　　　而後把bbs的虛擬目錄下面的.就用程序池..選擇剛纔新建的應用程序池...

　　　　而後再回到剛纔設好的應用程序池...點擊..屬性...把回收工做進程數(分鐘)及回收工做進程數還有在下列時間回收時間進程勾上..而後在下列時間回收程序池裏左邊添加..選擇一個時間..通常來講..網站到凌晨3點的時候.基本人都不多了..這時回收一下bbs的進程數..就能夠解決了iis(微軟的WEB服務器平臺)假死的現像..

　　　　固然還能夠配置其餘信息..好比說iis(微軟的WEB服務器平臺)6的用戶名.. 咱們能夠打開計算機管理..而後打開計算機用戶管理..添加一個用戶..設置好後..在應用程序池裏面..標識..把添加的用戶放上去..用用戶來測試回收的進程..固然還有..其餘配置..其實很簡單..只要好好看一下..就能明白意思...

　　　　也能夠藉助專用的工具來回收應用程序池..這樣方便並且快捷..iis(微軟的WEB服務器平臺)的備份.虛擬主機ip的統一修改及端口訪問的ip記錄..用批處理是一個很簡單又方便的方法.因此.把一臺服務器作的安全..並非哪麼容易的事..特別是iis(微軟的WEB服務器平臺)..常常去官方網站搜索資料是一