之前簡單說了下IIS的調優和監控,這里還幫朋友做了下 .NET Framework的監控分析并調優 ,插播這篇,留下點記憶。分析改進由于種種原因,Jason之后會換個方式講述的。
.NET Framework的調優主要是CLR(common language runtime)的調優,而其他實現技術的性能測試流程基本沒有什么變化,具體可以參考 性能測試workflow。
CLR的調優主要取決于你的架構和你代碼為CLR接受的程度,你的設計要更好的,有效的使用GC。我們怎么做可以提高GC的效率呢。
1.正確的使用合理的處理模式(Dispose pattern)。
2.嚴格規定事務的生命周期。
而CLR的瓶頸主要有 資源的競爭,資源清理的不有效, 濫用線程池 還有就是老問題內存泄露。
首先我們了解下如何識別CLR的瓶頸:
如果您的機器裝了.NET Framework,我們需要在perfmon下添加相應的監控計數器來監控性能并識別性能瓶頸。下面是推薦的計數器:
1.過度的內存消耗:主要由低效率的管理的內存消耗或者未管理的內存消耗導致。
* Process\Private Bytes
* .NET CLR Memory\# Bytes in all Heaps
* Process\Working Set
* .NET CLR Memory\Large Object Heap size
一般情況下,如果Process\Private Bytes不斷增長,如果.NET CLR Memory\# Bytes in all Heaps仍然保持不變,那么顯示為未管理內存消耗,如果一起增長即為管理的
內存消耗。
2.大工作集合的大?。汗ぷ骷癁楝F有加載在 RAM 上的內存頁的集合。
我們可以通過Process\Working Set來監控。如果值比較大,說明您可能加載了比較多數的assemblies。比較大的值或者值波動的現象出現可能意味著您的內存短缺。
一般情況下高值和波動值伴隨著高的內存頁錯誤直接顯示了您的服務器內存的不足。
3.大對象區:
一般大于83K的大對象會被分配到大對象區。.NET CLR Memory\Large Object Heap size主要監控1大對象區的情況,2讀寫buffers的情況。大對象可能造成大的內存堆棧碎片,所有我們要考慮在代碼端的recycling.
4.CPU的監控:CPU的usage直接關系到托管代碼的寫。
* % Time in GC.可以監控是否造成過度過量的GC。
* .NET CLR Exceptions\# of Exceps Thrown /sec.可以監控是否有大量的異常拋出。
* Thread\Context Switches/sec.這個我們需要監控是否有大量的線程產生,這一點與第5點結合將是解決并發問題的主要監控點。
5.線程競爭:
* .NET CLR LocksAndThreads\Contention Rate / sec
* .NET CLR LocksAndThreads\Total # of Contentions
我們需要以上兩個監控點來監控相應的線程資源利用情況。
如果線程競爭率或者線程競爭的數量呈明顯上升的時候,這時我們需要關注我們應用程序的線程競爭問題了。
我們大多數的分析都建立在這些性能監控點之上,而.NET的WEB應用程序性能的調優,遠不止這些,我們還需要在ASP.NET等不少地方下更大的功夫。
原文轉自:http://www.anti-gravitydesign.com