問題如下：
1.網(wǎng)頁上顯示

您試圖在此 Web 服務器上訪問的 Web 應用程序當前不可用。請點擊 Web 瀏覽器中的“刷新”按鈕重試您的請求。
管理員注意事項:
詳述此特定請求失敗原因的錯誤信息可在 Web 服務器的系統(tǒng)事件日志中找到。請檢查此日志項以查明導致該錯誤發(fā)生的原因。

2.windows事件查看器-應用程序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.

解決的方法很簡單，把程序對應的IIS應用程序池回收一下就好了。

可是為什么會出現(xiàn)這個原因呢？還有為什么回收一下就好了呢？回收做了些什么？
出現(xiàn)的原因
在網(wǎng)上搜索了一翻，發(fā)現(xiàn)主要是一下幾個問題，當然還有其他原因

1）.Framework的問題，例如1.0和2.0版本
2）aspnet_wp.exe 問題
3）安全更新程序 (KB886903)


可惜我們服務器出現(xiàn)的問題都不是以上幾點引起的，經(jīng)過我的分析認為是寫的很爛很爛的程序占用了大量的資源最后導致內(nèi)存泄漏，導致IIS的 進程當?shù)袅??？上Я顺绦蛭沂菦]辦法改，都是別人寫的，也不會改。不過我不可能每次出現(xiàn)這個問題就登陸到遠程服務器上去回收一次吧，所以只有讓他自動回收 了。

自動回收有好幾種方式，也不知道那一種比較適合，而且回收工作進程是會把保存在內(nèi)存里的Session清空，造成用戶需要重新登陸的問題，所以自動回收要越少越好，以保證不會因為其中的一個用戶使用了那個很爛的程式導致其他的用戶都要重新登陸。

如果用了狀態(tài)服務器或者是把Session保存到了數(shù)據(jù)庫中去的程序自動回收后肯定是沒有任何影響的，請求也不會中斷還是一樣繼續(xù)運行，只是換了個工作進程繼續(xù)為客戶端工作，客戶端是感覺不到的，當初沒有為了方便沒有把Session保存到數(shù)據(jù)庫真是失策！

1.根據(jù)運行時間
系統(tǒng)默認是1740分鐘,也就是29個小時,這個不是很好控制,建議不用，也就是去掉那個勾。

2.請求數(shù)目
這個要看具體的情況了。如果只有10個請求，可是有5個都在請求那個比較占資源的頁面（可能是統(tǒng)計年度報表之類），這個 時候就會出現(xiàn)進程當?shù)舻那闆r，如果請求有1000個可是一個也沒運行比較占資源的頁面，這個時候進程肯定是很正常的，所以根據(jù)請求的數(shù)目來決定也不符合實 際需要。

3.計劃的時間
這個其實很好，不過具體什么時間回收好呢？通常我們都是設置上班前和下班后回收，這個時候回收是有必要的，不過針對出現(xiàn)隨時可能出現(xiàn)是高內(nèi)存占用并不是很適用。

4.內(nèi)存（虛擬內(nèi)存或已使用的內(nèi)存）
這個針對出現(xiàn)內(nèi)存問題引起的進程當?shù)魧嵲谔线m了，不過設置多大的值比較好是一個很重要的問題， 我是根據(jù)每次出現(xiàn)問題時進程是實際占用情況決定的。我們的服務器內(nèi)存是2G，通常其他的一些服務會占用掉600多M，我發(fā)現(xiàn)有每次進程都是到1G多的時候 當?shù)?，所以設置了最大使用內(nèi)存為1000M的時候自動回收，設置后一直都沒出現(xiàn)問題了。要查看進程的占用直接用windows任務管理器就好，值不能太小 了，否則如果訪問量都很大超過這個值的時候也會自動回收，這個就很沒必要了。一定要多多觀察進程的實際占用情況再做決定。
在IIS的配置文件里面 如果配置了IIsApplicationPools節(jié)點的LogEventOnRecycle屬性，每次回收的時候IIS的日志文件會根據(jù) LogEventOnRecycle屬性的值紀錄下相關的信息，也個也是設置自動回收時的一個重要參考，不過由于這個日志文件只能看幾個小時以前的紀錄， 當前的紀錄要幾個小時后才寫進去，所以看起來不方便，郁悶！


現(xiàn)在暫時根據(jù)最大占用內(nèi)存自動收回以前的問題是解決了，暫時也發(fā)現(xiàn)什么新問題了，也不知道其他地方都是怎么設置的，是不是還有更好的方法呢？希望到了這篇文章的人能提點寶貴意見，大家一起交流一下經(jīng)驗。

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

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



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

工作進程回收如何工作
根據(jù)應用程序池回收的配置方式，萬維網(wǎng)發(fā)布服務（WWW 服務）可以使用兩種方法來回收已分配的工作進程：

•默認情況下，WWW 服務建立“重疊回收”，即繼續(xù)運行要終止的工作進程，直到啟動新的工作進程后為止。
•或者，WWW 服務可以終止一個工作進程，然后啟動一個新的工作進程（如果工作負荷允許執(zhí)行此操作的話）。

注意 當 WWW 服務回收某個工作進程時，它并不斷開現(xiàn)有的 TCP/IP 連接。HTTP 協(xié)議堆棧 (HTTP.sys) 建立并維護 TCP/IP 連接。

在重疊回收方案中，要回收的進程繼續(xù)處理請求，同時 WWW 服務創(chuàng)建一個替代工作進程。在停止舊工作進程之前啟動新的工作進程，然后將請求定向到新的進程。此設計可以防止服務中斷，因為舊進程關閉前仍然保持與 HTTP.sys 的通信以處理請求。因為可重疊關閉或啟動的關閉超時值是可以配置的，所以在工作進程仍在處理請求的同時可以終止該進程（如果它在時間限制內(nèi)沒有處理完請求 的話）。

在配置應用程序池以基于運行時間來回收工作進程時，可以在設置的運行時間內(nèi)回收所有的工作進程，但不能同時回收所有這些工作進程?？梢栽谠O置的時間內(nèi)的不同時段進行回收應用程序，以減少客戶端請求服務的中斷次數(shù)。

類似地，在配置應用程序池以基于處理請求的數(shù)目來回收應用程序時，可以每隔一段時間回收一次以分擔與工作進程回收有關的系統(tǒng)開銷。

何時使用工作進程回收
在決定是否啟動工作進程回收時，應考慮以下常規(guī)指南。最佳的解決方案是修復引起故障的應用程序。但是，并非總能使用重新編碼，尤其是運行的其他應用程序代碼無法修改時。

在以下情況下考慮使用回收：

• 無法修復 Web 服務器上您所主控的有故障的應用程序。
• 遇到不能確定的或間斷性的故障。
• 您懷疑應用程序由于性能監(jiān)視的原因而泄漏內(nèi)存。
• 先前已實施了臨時性的重置解決方案，例如，計劃執(zhí)行 IISReset 命令行實用工具。

在以下情況下，可能根本不需要使用回收：

• 您所主控的網(wǎng)站只包含靜態(tài)內(nèi)容，并且不包含自定義 Internet 服務器 API (ISAPI) 應用程序。
• 您所主控的應用程序已經(jīng)過完全測試，并且不會出現(xiàn)內(nèi)存或資源分配問題。

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

回收依據(jù)的條件	描述	使用時間
ISAPI 請求	根據(jù)應用程序池中 ISAPI 的請求回收工作進程。	ISAPI 擴展可以將其自身聲明為運行狀況差。
運行時間	根據(jù)用戶指定的時間（分鐘）回收工作進程。	存在故障的應用程序的運行時間過長。
請求數(shù)目	當超文本傳輸協(xié)議 (HTTP) 請求超出某個特定閾值時回收工作進程。	根據(jù)應用程序接收到的請求數(shù)目，應用程序出現(xiàn)故障。
計劃的時間	在 24 小時內(nèi)的指定時間進行回收。	條件與運行時間的條件類似。
虛擬內(nèi)存（保留的內(nèi)存加上已使用的內(nèi)存）	當工作進程虛擬內(nèi)存達到某個特定閾值時回收該工作進程。	內(nèi)存堆棧碎片過多（這是由于應用程序保留多次內(nèi)存造成的）。癥狀是虛擬內(nèi)存持續(xù)增加。
已使用的內(nèi)存	當 W3wp.exe 進程使用的內(nèi)存達到某個特定閾值時回收工作進程。	某些應用程序出現(xiàn)內(nèi)存泄漏。
根據(jù)需要	當 IIS 管理員可以使用 Microsoft? 管理控制臺 (MMC) 或腳本控制整個應用程序池的回收時開始回收。	在其他站點啟動并運行時，有一個引起故障的應用程序池。請考慮回收該應用程序，而無需重置整個 WWW 服務。

最新評論