2010-02-26 57 views
4

雖然試圖用託管nt服務重現報告的問題,但我注意到性能計數器「Jitted方法數量」不斷增加(連同「IL字節數Jitted」)。報告的行爲包括大量的內存(不一定是機器上可用的所有內存)並消耗100%的CPU。對此nt服務的請求(通過wcf)通常會導致超時,即超過90秒。 (這些請求源於同一臺機器上的一個asp.net站點。)應該如何解釋性能計數器「Jitted方法」?

經過15分鐘預熱時間後,數值爲127k(3610kb),經過一小時後爲246k(6427kb),即增加119k jitted方法。

我不認爲這是單獨的這種行爲導致報告的問題,因爲報告的運行時間之前破壞只有幾個小時。

但是,我仍然對如何解釋這[顯然]不斷增加的數字感興趣。雖然每小時只有3 MB,但每週將達到500 MB。而且,任何人都知道「IL字節數」是否是垃圾收集的主題?

(期間拍攝20分鐘的時間寫這篇文章的方法的人數增加了33K,和字節數與〜300K)

澄清,我應該提到第一次
事...;)

  • 我們沒有創建,加載或卸載任何應用程序域的代碼。
  • 我們沒有發現任何東西,並且使用C#3,所以沒有動態對象。
  • 我們使用NHibernate和AutoMapper,都使用反射來解決他們的目標。但是,我認爲這些庫行爲良好,並且不會導致這種行爲。 (在那裏的任何工具,它讓我看到的即時編譯哪些方法?)

變化

  • 刪除的代碼行數和實時編譯的方法數之間的比較。 Oded指出,該計數器還包括.NET Framework中的方法。

回答

1

jitted的行數包括框架和第三方庫代碼。

這不是C#,VB.NET行,而是CIL行,它們有更多的行 - 這可能足以解釋這種差異。

3

可能有很多原因爲什麼一個進程會繼續檢查代碼。如果您在特定AppDomain中加載程序集,則如果您在另一個AppDomain中加載程序集(除非程序集加載爲域中立),將重新編譯相同的方法。

生成和運行動態方法也會導致所有新方法的連接。

垃圾收集。 GC僅清理管理的對象堆。 Jitted代碼存儲在AppDomain的代碼堆中,因此不會被GC收集。卸載AppDomain將擺脫該域的代碼堆。

這個帖子有更多的細節http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

更新:關於工具

的WinDbg + SOS救援中心會告訴你哪些方法已經每種類型即時編譯。使用!dumpmt -md。您還可以使用!dumpdomain命令查看每個AppDomain中加載了哪些模塊。但是,它可能需要一點點挖掘才能找到您要查找的細節。