構建高效能.NET應用之配置高可用IIS伺服器-第五篇 IIS常見問題之：背景工作處理序回收機制（中）

 

我們在本篇中接著講述“背景工作處理序回收機制”。

本篇文章的議題如下：

               背景工作處理序回收機制講解

基於時間的回收機制

               基於請求數的回收機制

               基於記憶體使用量的回收機制

基於活動狀態的回收機制

 

                

系列文章：

構建高效能.NET應用之配置高可用IIS伺服器-第一篇：IIS必須掌握的知識 

構建高效能.NET應用之配置高可用IIS伺服器-第二篇 IIS請求處理模型構建高效能.NET應用之配置高可用IIS伺服器-第三篇 IIS中三個核心組件的講解（上） 構建高效能.NET應用之配置高可用IIS伺服器-第三篇 IIS中三個核心組件的講解（下） 構建高效能.NET應用之配置高可用IIS伺服器-第四篇 IIS常見問題之：背景工作處理序回收機制（上） 

基於請求數的回收機制

       這種基於請求數量回收的機制非常的好理解：當我們的應用程式收到的請求數量達到了一個閥值之後，就開始對應用程式集區中的背景工作處理序使用的資源進行回收，設定的方法和之前講述的基於時間的基本類似，

 

       其實很多的時候，引起這種回收機制的原因都是應用程式已經無法處理過多的請求，導致了請求處理失敗，而不得不開始運行這種回收機制。

 

基於記憶體使用量的回收機制

       應用程式集區的回收是可以通過它所使用的記憶體來設定的，可以通過設定它已經使用的記憶體和它的虛擬記憶體兩個方面來決定何時進行回收，大致的情況如：

 

 

       我們使用基於記憶體的背景工作處理序回收機制可以在一定的程度上面防止記憶體泄露或者記憶體資源過度分派的情況。同時，有一個需要清楚的的就是：很多的時候，我們的Web應用程式的效能在很大的程度上來依賴緩衝，特別是在ASP.NET中使用它的緩衝API的時候，我們要非常的清楚這些問題。       快取資料空間的大小不是無限制的，它的大小是可以配置的，並且有可能出現這樣的一種情況：資料在前一秒緩衝進入，下一秒在使用的時候緩衝的資料就沒有了，可能就會導致“找不到對象“等問題，這個時候，原因就是設定的緩衝空間大小已經達到了設定值，導致了背景工作處理序回收，使得資料全部丟掉。更多的關於這個方面的講述，可以參看我的另外的一篇文章：使用緩衝的9大誤區(上)

 

另外，設定基於記憶體使用量的回收機制，可以讓回收機制“監控“記憶體的時候，防止之前所說的記憶體泄露等情況。

說了這麼多，那麼我們就來看看如何來設定基於記憶體的回收機制。

 

專用記憶體使用量情況（Private bytes） 

       這個設定可以限制在一個背景工作處理序被回收之前可以使用的專用的不共用的記憶體的大小。其實說到這裡，估計有些朋友又開始不明白了，因為這已經涉及到了Window記憶體管理的一些知識，大家可以參看這篇文章：window記憶體管理知識普及 。

       註：可以說Window記憶體，進程調度等知識都是效能最佳化過程中需要掌握的基礎，其實現在很多的開發人員是完全不懂這些東西，僅僅只是知道C#文法，然後使用基本的文法規程編程，如果真是這樣，技術很難提升到很高的層面。

 

在IIS6中，這個設定在應用程式“屬性“的“回收“選下卡中，被稱之為“最大使用的記憶體“，單位是Mb，如下：

 

 

       在IIS7中就稱之為“專用記憶體”（其實也是核心模式可使用的記憶體數量），單位為Kb。

       這個值的設定對ASP.NET應用中的緩衝和Session使用至關重要。如果這個值設定的太小，同時我們的應用程式又是非常大的依賴緩衝，那麼，就會導致背景工作處理序頻繁的被回收，很多的在進程中儲存的資料就會丟失，後果可想而知。

 

       在ASP.NET2.0以後，緩衝機制通過使用緩衝剪裁策略來避免背景工作處理序回收。什麼意思呢？

 

     就是，緩衝機制會根據一些策略（例如，最近最少使用演算法等）來將緩衝中的一些資料移除，將閒置位置讓給別的資料，從而避免緩衝空間使用過大，從而避免了記憶體的使用太多而達到回收的閥值。我們可以在web.config中使用privateBytesLimit設定來配置緩衝裁剪的層級，如下：

 

 

       下面我們就看看在預設的情況下，何時出現緩衝剪裁的問題：

使用者模式記憶體大小
<=2GB	>2GB(32位的作業系統)	>2GB(64位作業系統)
60%*實體記憶體或者800Mb	60%*實體記憶體或者800Mb	60%*實體記憶體或者1TB

 

       上面的表格比較簡單，我這裡只是稍微的講述一下（以使用者模式記憶體小於2GB為例子）：如果作業系統中進程的使用者模式的記憶體小於2GB，那麼privateBytesLimit的值就會是：60%*實體記憶體（例如，我們配置的記憶體條的大小為4GB），如果配置的實體記憶體條的大小實太小了，例如1GB，那麼此時60%*1GB=600Mb，此時privateBytesLimit就不會按照這個來設定值，而是直接取800Mb。

 

       同時，除了設定privateBytesLimit的固定值之外，我們還可以按照比例來設定，使用percentagePhysicalMemoryUsedLimit來設定當記憶體使用量多少之後就開始對緩衝進程裁剪，這是一個動態過程，它可以自行計算。另外，這個值也可以有效減少.NET記憶體回收機制的運行，提升效能。

      

虛擬記憶體使用方式（Virtual bytes）

       在這裡，我就沒有必要介紹虛擬記憶體的概念了。關於虛擬記憶體的問題也是非常的難以診斷和發現的，虛擬記憶體的問題主要就是片段的問題。

       當進程在啟動並執行時候，它是由一個最大的虛擬記憶體大小的，例如，在Win32的作業系統中，就是4GB，使用者模式與核心模式各是2GB（在沒有使用/3GP的情況下）。當進程中的程式需要記憶體的時候，虛擬記憶體管理器會去分配一個空間，久而久之就可能導致虛擬記憶體產生很多的片段，導致後續的記憶體配置無法進行，而產生”Out Of Memory”的問題。

 

       其實，我們也沒用非常好的辦法來避免這個問題，但是可以通過一些經驗來緩解，例如，我們可以設定當虛擬記憶體空間使用了70%的時候就啟動回收，同時，我們也可以通過監視Process/Virtual Bytes這個效能計速器來分析資料。

 

 

 

 

 

系列文章連結：

IIS負載平衡-Application Request Route詳解第一篇： ARR介紹  

IIS負載平衡-Application Request Route詳解第二篇：建立與配置Server Farm

 IIS負載平衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載平衡（上） 

IIS負載平衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載平衡（下） 

IIS負載平衡-Application Request Route詳解第四篇：使用ARR實現三層部署架構

 

負載平衡原理與實踐詳解 第一篇（重新整理）  

負載平衡原理與實踐詳解 第二篇（重新整理）  

負載平衡原理與實踐詳解 第三篇 伺服器負載平衡的基本概念-網路基礎  

負載平衡原理與實踐詳解 第四篇 使用負載平衡器的伺服器群   

負載平衡原理與實踐詳解 第五篇 負載平衡時資料包流程詳解  

負載平衡原理與實踐詳解 第六篇 健全狀態檢查機制詳解（上）  

負載平衡原理與實踐詳解 第七篇 健全狀態檢查機制詳解（下）  

負載平衡原理與實踐詳解 第八篇 網路位址轉譯（上）

負載平衡原理與實踐詳解 第八篇 網路位址轉譯(下)

負載平衡原理與實踐詳解 第九篇 伺服器負載平衡技術進階-會話保持（上）

負載平衡原理與實踐詳解 第十篇 伺服器負載平衡技術進階-會話保持（中） 負載平衡原理與實踐詳解 第十一篇 伺服器負載平衡技術進階-會話保持（下） 之：延遲綁定