IIS6.0應用程序池回收設置分析
2024-08-29 03:12:29
供稿：網友
問題如下：
1.網頁上顯示
您試圖在此 Web 服務器上訪問的 Web 應用程序當前不可用。請點擊 Web 瀏覽器中的“刷新”按鈕重試您的請求。
管理員注意事項:
詳述此特定請求失敗原因的錯誤信息可在 Web 服務器的系統事件日志中找到。請檢查此日志項以查明導致該錯誤發生的原因。
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應用程序池回收一下就好了。
可是為什么會出現這個原因呢？還有為什么回收一下就好了呢？回收做了些什么？
出現的原因
在網上搜索了一翻，發現主要是一下幾個問題，當然還有其他原因
1）.Framework的問題，例如1.0和2.0版本
2）aspnet_wp.exe 問題
3）安全更新程序 (KB886903)
可惜我們服務器出現的問題都不是以上幾點引起的，經過我的分析認為是寫的很爛很爛的程序占用了大量的資源最后導致內存泄漏，導致IIS的 進程當掉了?？上Я顺绦蛭沂菦]辦法改，都是別人寫的，也不會改。不過我不可能每次出現這個問題就登陸到遠程服務器上去回收一次吧，所以只有讓他自動回收 了。
自動回收有好幾種方式，也不知道那一種比較適合，而且回收工作進程是會把保存在內存里的Session清空，造成用戶需要重新登陸的問題，所以自動回收要越少越好，以保證不會因為其中的一個用戶使用了那個很爛的程式導致其他的用戶都要重新登陸。
如果用了狀態服務器或者是把Session保存到了數據庫中去的程序自動回收后肯定是沒有任何影響的，請求也不會中斷還是一樣繼續運行，只是換了個工作進程繼續為客戶端工作，客戶端是感覺不到的，當初沒有為了方便沒有把Session保存到數據庫真是失策！
1.根據運行時間
系統默認是1740分鐘,也就是29個小時,這個不是很好控制,建議不用，也就是去掉那個勾。
2.請求數目
這個要看具體的情況了。如果只有10個請求，可是有5個都在請求那個比較占資源的頁面（可能是統計年度報表之類），這個 時候就會出現進程當掉的情況，如果請求有1000個可是一個也沒運行比較占資源的頁面，這個時候進程肯定是很正常的，所以根據請求的數目來決定也不符合實 際需要。
3.計劃的時間
這個其實很好，不過具體什么時間回收好呢？通常我們都是設置上班前和下班后回收，這個時候回收是有必要的，不過針對出現隨時可能出現是高內存占用并不是很適用。
4.內存（虛擬內存或已使用的內存）
這個針對出現內存問題引起的進程當掉實在太合適了，不過設置多大的值比較好是一個很重要的問題， 我是根據每次出現問題時進程是實際占用情況決定的。我們的服務器內存是2G，通常其他的一些服務會占用掉600多M，我發現有每次進程都是到1G多的時候 當掉，所以設置了最大使用內存為1000M的時候自動回收，設置后一直都沒出現問題了。要查看進程的占用直接用windows任務管理器就好，值不能太小 了，否則如果訪問量都很大超過這個值的時候也會自動回收，這個就很沒必要了。一定要多多觀察進程的實際占用情況再做決定。
