性能计数器“# of Methods Jitted”应该如何解释？答案

【问题标题】：How should the performance counter "# of Methods Jitted" be interpreted?性能计数器“# of Methods Jitted”应该如何解释？
【发布时间】：2010-02-26 22:37:26
【问题描述】：

在尝试使用托管 nt 服务重现报告的问题时，我注意到性能计数器“# of Methods Jitted”不断增加（与“# of IL Bytes Jitted”一起）。报告的行为包括占用大量内存（不一定是机器上可用的所有内容）和消耗 100% 的 cpu。对此 nt 服务的请求（通过 wcf）通常会导致超时，即 90 多秒。（请求来自同一台机器上的 asp.net 站点。）

15 分钟预热时间后，该值为 127k (3610 kb)，一个小时后为 246k (6427 kb)，即增加了 119k jitted 方法。

我不认为仅此行为会导致报告的问题，因为报告的服务破坏之前的运行时间只有几个小时。

但是，我仍然对如何解释这个 [显然] 不断增加的数字感兴趣。虽然每小时只有 3 mb，但每周将达到 500 mb。另外，有人知道“# of IL Bytes Jitted”是否是垃圾收集的主题？

（在写这篇文章的 20 分钟内，方法数量增加了 33k，字节数增加了约 300k。）

澄清
我应该第一次提到的事情......;）

我们没有创建、加载或卸载任何应用程序域的代码。
我们不发射任何东西，并且使用 C# 3，所以没有动态对象。
我们正在使用 NHibernate 和 AutoMapper，它们都使用反射来解决它们的目标。但是，我认为这些库表现良好并且不会导致这种行为。（有什么工具可以让我看到哪些方法被 jit 了？）

变化

删除了代码行数和 jitted 方法数之间的比较。正如 Oded 所指出的，计数器还包括 .NET Framework 中的方法。

【问题讨论】：

标签： .net performance jit

【解决方案1】：

进程继续抖动代码的原因可能有很多。如果您在特定 AppDomain 中加载程序集，如果您在另一个 AppDomain 中加载程序集（除非程序集作为域中性加载），相同的方法将被重新设置。

生成和运行动态方法也会导致所有新方法的抖动。

关于垃圾回收。 GC 只清理托管对象堆。 Jitted 代码存储在 AppDomain 的代码堆中，因此不会被 GC 收集。卸载 AppDomain 将删除该域的代码堆。

这篇文章有更多细节http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

更新：关于工具

WinDbg + Sos 将向您显示每种类型已被 jitted 的方法。使用!dumpmt -md。您还可以使用!dumpdomain 命令查看每个 AppDomain 中加载了哪些模块。但是，可能需要花一些时间才能找到您正在寻找的细节。

【讨论】：

【解决方案2】：

Jitted 的行数包括框架和第三方库代码。

这不是 C#、VB.NET 行，而是 CIL 行，还有很多行 - 这可能足以解释差异。

【讨论】：