建構高性能.NET應用之配置高可用IIS伺服器-第四篇 IIS常見問題之：工作程序回收機制（上）

通過三篇文章的普及，相信大家對IIS應該有了一個基本的了解。那麼從本篇文章開始，我們就開始進入IIS一些比較實際的話題：如何配置IIS，使得其性能盡可能的高。

系列文章：

       我們在本篇中主要講述的就是“工作程序回收機制”，下面我們就來具體的看看。

       本篇文章的議題如下：

               工作程序回收機制講解

基于時間的回收機制

               基于請求數的回收機制

               基于記憶體使用的回收機制

               基于活動狀态的回收機制

工作程序回收機制講解

       在IIS6和IIS7的應用程式池中，可以進行一系列的配置來控制如何啟動和停止池中的工作程序。合理的配置可以使得應用程式的可用性更高，特别是出現問題的時候，可以盡可能的減少損失。通過配置，可以使得應用程式池中，一些運作的比較慢或者将要失敗的程序可以被快速的結束，進而使用新的程序來取代它們。

       回收機制與啟動機制不同，因為回收機制是屬于比較智能的政策，回收機制允許一個程序在被回收之前先處理完現有的任務，而重新開機機制則是強制關閉。使用回收機制，可以在舊的程序還在處理之前的請求的時候，同時開啟新的程序，使得新的請求被新程序處理。

       有一點要清楚的就是：當一個工作程序被回收的時候，任何儲存在程序中的狀态都會被清理掉，例如session，cache。如果我們要確定運作狀态，例如session，cache等不随着工作程序的回收而清理，那麼就必須采用其他的方式來儲存狀态，而不是直接儲存在工作程序的記憶體中，例如，對session可以采用資料庫存儲的方式，對cache可以采用分布式緩存來實作。

下面，我們就來看看工作程序被回收的幾個政策，或者說，什麼時候啟動回收機制。

在講解之前，我們可以檢視一下應用程式池中回收機制的配置，如圖是IIS7的：

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=332" target="_blank"></a>

點選“正在回收”之後，看到如下的界面：

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=334" target="_blank"></a>

除了上面的看出方式之外，我們還可以進入應用程式池的“進階設定”程序配置，如圖：

然後在“回收”進行設定，如圖：

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=336" target="_blank"></a>

       大家可以看到，我們這裡可以基于很多不同的政策進行配置，而這些也使我們本篇文章要講的，下面我們就來具體的看看每一種回收政策以及具體的配置的資訊。

基于時間的回收機制      

       這個回收政策應該是比較容易了解的，就是對時間進行設定，來決定什麼時候，或者間隔多長時間來回收。

固定時間收集的間隔

       通過這個配置項，我們可以設定應用程式池每個多長的時間（分鐘）去對池中的工作程序進行資源的回收，預設是1760分鐘，也就是一天。如果我們的應用程式在還沒有達到這個時間間隔就失敗了，出現了問題,那麼，我們就要把這個值設定為失敗時間的80%。

       舉例來說，如果一個應用程式，在1000分鐘之類就失敗，那麼它所占用的是無法被回收的，因為回收的時間被設定為1740分鐘之後，如果我們放任這種情況，那麼伺服器的資源就會被耗盡。此時，我們可以通過多次的資料取樣，擷取平均的失敗時間間隔，假設是1000分鐘，那麼這個時候，我們就把這個“固定時間收集的間隔”設定為800分鐘。這個配置在某些情況下可以是一個應急的解決方案，可以快速的搞定資源洩露的問題，但是需要技術人員真正的解決站點運作失敗的原因。

設定回收的時間間隔

       另外一種比較回收方法就是設定在一天中的那些時候去進行回收。設定如下：

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=337" target="_blank"></a>

      我們可以控制在哪個時間點去進行回收，特别實在診斷問題的時候。如果我們發現在某個點，站點總是不能出來請求或者資源的使用過多（例如，站點通路高峰值的時候），我們可以通過設定，使得資源盡快的被回收。

       今天就到這裡，下篇接着講述！

系列文章連結：

<a href="http://www.agilesharp.com/u/yanyangtian/Blog.aspx/t-199">IIS負載均衡-Application Request Route詳解第二篇：建立與配置Server Farm</a>

<a href="http://www.agilesharp.com/u/yanyangtian/Blog.aspx/t-206" target="_blank">IIS負載均衡-Application Request Route詳解第四篇：使用ARR實作三層部署架構</a>

<a href="http://www.agilesharp.com/u/yanyangtian/Blog.aspx/t-223" target="_blank">負載均衡原理與實踐詳解 第八篇 網絡位址轉換（上）</a>

<a href="http://www.agilesharp.com/u/yanyangtian/Blog.aspx/t-229" target="_blank">負載均衡原理與實踐詳解 第八篇 網絡位址轉換(下)</a>

<a href="http://www.agilesharp.com/u/yanyangtian/Blog.aspx/t-231" target="_blank">負載均衡原理與實踐詳解 第九篇 伺服器負載均衡技術進階-會話保持（上）</a>

本文轉自yanyangtian51CTO部落格，原文連結http://blog.51cto.com/yanyangtian/836518： ，如需轉載請自行聯系原作者