構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前中篇)—託管資源最佳化—監測CLR效能
前言:在上一篇文章中講述了一些記憶體回收的一些知識,本篇就講述如何來監測CLR是否導致了一些效能問題。
本篇的議題如下:
記憶體問題概述(前篇)
託管資源最佳化(前篇)
對象的生命週期(前篇)
對象的”代“(前篇)
大對象堆(LOH) (前篇)
CLR計數器的使用 (中篇)
CLR Profiler的使用(中篇)
記憶體回收行程的不同版本(中篇)
對象使用注意事項(後篇)
常用最佳化措施(後篇)
非託管資源最佳化
Session會話的最佳化
系列文章連結:
構建高效能ASP.NET網站 開篇
構建高效能ASP.NET網站之一 剖析頁面的處理過程(前端)
構建高效能ASP.NET網站之二 最佳化HTTP請求(前端)
構建高效能ASP.NET網站之三 細節決定成敗
構建高效能ASP.NET網站 第五章—效能調優綜述(前篇)
大型高效能ASP.NET系統架構設計
構建高效能ASP.NET網站 第五章—效能調優綜述(中篇)
構建高效能ASP.NET網站 第五章—效能調優綜述(後篇)
構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優(上篇)—識別效能瓶頸
構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優(下前篇)—簡單的最佳化措施
構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優(下後篇)—減少不必要的請求
構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前篇)—託管資源最佳化—記憶體回收機制深度剖析
構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前中篇)—託管資源最佳化—監測CLR效能
CLR計數器的使用
我們使用系統內建的效能監測工具來跟蹤和監測記憶體回收行程。
下面,首先介紹幾個常用的CLR效能監測計數器,我們一般查看.NET CLR Memory分類下的計數器:
Percent Time in GC |
表明了從上次記憶體回收機制運行之後到現在這段時間內,運行記憶體回收機制所花的時間佔總時間的百分比。不要超過10%。 |
Gen 0 heap size |
這個數值不是表明當前託管堆中Gen 0對象所佔的大小,而是指:還可以分配的Gen 0對象的大小 |
Gen 1 heap size |
表明當前Gen 1 對象所佔的託管堆的空間大小 |
Gen 2 heap size |
表明當前Gen 2 對象所佔的託管堆的空間大小 |
Large Object Heap size |
當前LOH的大小 |
# Byte in all Heaps |
是上面Gen 0 heap size,Gen 1 heap size,Gen 2 heap size,Large Object Heap size所有的種和,也就是整個託管堆所佔的空間大小 |
# Gen 0 Collections |
從系統開啟之後到現在,記憶體回收行程回收Gen 0對象的次數 |
# Gen 1 Collections |
從系統開啟之後到現在,記憶體回收行程回收Gen 1對象的次數 |
# Gen 2 Collections |
從系統開啟之後到現在,記憶體回收行程回收Gen 2對象的次數 |
介紹完上面的一些計數器之後,大家可以運行”perfmon”命令,開啟效能監測工具。
下面開始介紹CLR Profiler(CLR 透析器)
CLR Profiler
CLR Profiler是微軟開發的一個工具,這個工具可以用來檢測CLR所佔用的記憶體詳情。
大家可以去下面的連結去下載這個工具:
http://www.microsoft.com/downloads/details.aspx?familyid=a362781c-3870-43be-8926-862b40aa0cd0&displaylang=en
下面的連結詳細的講述這個工具的用法:
http://msdn.microsoft.com/zh-cn/magazine/ee309515.aspx#MtViewDropDownText
在這裡,只是簡單的介紹一下如何使用,至於詳細的操作,還請大家去查看上面給出的連結。使用的步驟如下:
1. 運行CLR Proflier
2. 確保”Profiling active, Allocations, Calls”都勾選上。如下:
3. 選擇”File->Profile ASP.NET”.這個操作的背後會停止IIS的運行,然後插入一些指令,然後重啟IIS,所以這個工具在生產環境中慎用。
4. 然後我們可以在VS中F5運行我們的網站(確保在建立網站的時候是以IIS方式來建立網站的,而不是選擇”檔案系統”的方式建立)
5. 在介面上面點擊”Kill ASP.NET”.這個操作的背後會移除之前加入到IIS中的一些監視指令。點擊按鈕之後,會出現一些介面。這個介面上面顯示了Gen0, Gen1 Gen2 ,LOH所佔的大小,如下:
6. 我們還可以點擊”Histogram”按鈕。這個介面展示了不同大小以及不同類型的對象所佔的比例。下面對看出,系統中有很多的string對象,也就說,系統中的string類型的對象佔據了系統大部分的記憶體空間。
大家可以查看更多的資訊,這裡不再贅述了,下面我們來看看記憶體回收行程的版本問題。
記憶體回收行程版本
在CLR中,記憶體回收行程是有兩個版本的:
1. 服務端版本。CLR中的這個記憶體回收行程版本進行了一系列的記憶體,處理器最佳化,用來進一步的提高效能。
2. 工作群組版本,這是相對服務端版本而言的,主要是用在案頭開發中,例如在WPF,Winform中,就是採用的這個版本記憶體回收行程。
在ASP.NET中就是採用的CLR服務端版本的記憶體回收行程。
OK,今天就暫時寫到這裡,下一篇講述一些針對上述問題的一些最佳化措施。