與GC相關的效能計數器

如果遇到了效能問題,在使用debug之前分析問題較為不錯的一個工具就是perfmon.解決問題最好的方法是思考,這也是熊力大哥在其書中一直在強調的.

如果您的網站遇到下面的幾種情形,那還是先看看perfmon裡GC相關的東西吧:

1. cpu佔用高,記憶體佔用不高.
2. cpu和記憶體佔用都比較高
3. cpu和記憶體佔用都不高,但是網站響應很慢

開啟perfmon找到.NET CLR Memory後下面有好幾個counter,從哪個開始看呢?

1) % Time in GC

這 個值是說從上一次GC結束到當前這次GC的時間的百分比. 比如上次GC結束時經曆了100w個迴圈,當前的GC消耗是50w個迴圈,這個計數器的值就是50%. 看perfmon的各個counter來推測究竟是什麼問題,主要有兩類情況,第一類需要看counter到變化趨勢,第二類需要看到是counter到 值.這裡對待第2類情況引入一個"健康值"的概念.當然這些只是大方向上來說到,並不是100%到準確的適應大多數情況.

那麼這個值為多少合適呢? 一般來說如果這個值>50%了我們應該去檢查一下託管堆的問題.如果這個值不大,沒有太大的必要去最佳化程式了.

2)Allocated Bytes/sec

如 果認為在GC上花費的時間太多了,接下來應該看看Allocated Bytes/sec這個counter,它顯示了分配速率.需要注意到是這個counter到值在分配速率很低的情況下其實是不準確的,這個值只有在每次 GC開始的時候才會被更新,如果perfmon到取樣頻率（預設是1秒）大於GC的頻率的時候，這個值就不太容易說明問題了。

當有分配請求不能被完成時，會觸發GC：

1. Gen0滿了，不能滿足最後一次的小對象的分配請求
2. LOH滿了，不能滿足最後一次的大對象分配請求

所以當GC開始的時候會更新該計數器到值——將Gen0和LOH想加的和加到這個值上，然後與上一次的值相加再除以時間間隔。得到的就是這個分配速率。

舉 個例子：預設情況下perfmon1秒更新一次資料，在第1秒Gen0 GC因為需要分配100k而觸發，所以再第1秒末這個值是(100k-0k)/1sec，是100k/sec。在第2秒沒有GC發生，記錄的值還是 100k，那麼第2秒末該值就是(100k-100k)/1sec,是0k/sec，第3秒Gen0 GC又被觸發總共被分配了200k，所以在第3秒末的時候這個值是(200k-100k)/1sec，是100k/sec。

從上面到例子能看到如果說GC發生的不是非常頻繁的話這個值應該是0k/sec的。

3)Large Object Heap Size

這個值只是記錄在LOH裡的bytes。

OK。 到這一步為主，我們可以看出導致GC做大量工作的一個關鍵因素就是較高的分配速率。大家都知道GC是分Generation的，從Gen0到Gen2，如 果一個對象在Gen0到時候就死了，我們況且成它為“夭折”（die young），另一類生命力看似頑強但是到了Gen2立刻掛掉的，我們稱之為“中年危機”（die at Gen2）。

所以如果都在GC Gen0完成後就結束工作了，花在GC上的時間百分比是不會高的。畢竟Gen0到GC只會佔用非常短暫的時間。

但是Gen2的GC就不這樣了，它會從Gen0到Gen2，再加上LOH的。LOH的GC也是很消耗資源的工作，但是並沒有只針對LO的回收，所以即使LOH還有空間可供分配，但是Gen2滿了，也會導致LOH跟著一起遭殃。

通常來說這三個代的GC速率在100：10：1是不錯的。

4)# Gen X Collections

X到值為0，1和2。需要注意的一點是Gen1會一次性的回收Gen0和Gen1。

如果有大量的Gen2上的GC，就意味著有大量的對象存活了太長時間，但是還沒長到他們要一直在Gen2裡生存。如果看到了GC消耗了很多時間但是分配速率卻不高的話，最大的可能就是很多個物件在不斷的從Gen0到Gen2被不斷的提升。

5)Promoted Memory from Gen 0/1和 Promoted Finalization - Memory from Gen 0

這三個值是看提升（promotion）情況的。被finalization引發的對象的提升要看後者，是不包括在前面兩個counter裡的。但是後者雖然說是from Gen 0的，但是其實同時包含了Gen0和Gen1的。

這時可能出現一種最壞的情況：一個對象存活了很久，最終被提升到Gen2，但是一進入Gen2立刻就死掉了，也就是上述的“中年危機”。當遇到這個情況Promoted Memory from Gen1到只是比較高的，而且有大量的Gen2 GC。

需要注意到是當一個finalizable的對象存活時，所以他引用的對象也都是存活的，Promoted Finalization-Memory from Gen0的計數器也包含了這些對象。

6)Gen 1/2 heap size

當看到這些提升相關的計數器的值比較高時，應該看看這兩個counter。他們的意思從名字就能看出。

需要注意Gen 0 heap size到值是假的，它其實是一個預算，指示下一次什麼時候進行GC的。

Gen0和Gen1都很小，從256k到幾兆。

7)# Total committed Bytes和# Total reserved Bytes

# Total committed Bytes= Gen0 heap size + Gen 1 heap size + Gen 2 heap size + LOH size

後者到值要比前者的值大.

8)# Induce GC

如果看到這個值比較高那就比較慘了,檢查代碼中GC.Collect()是不是調用了太多了.這種使用和設定IIS檢測到memory漲到一定程度自動回收一樣,都不是真正解決問題的方法.