4

管理された nt サービスで報告された問題を再現しようとしているときに、パフォーマンス カウンター "# of Methods Jitted" が ("# of IL Bytes Jitted" と共に) 常に増加していることに気付きました。報告された動作は、大量のメモリ (必ずしもマシンで利用可能なすべてではない) を使用し、100% の CPU を消費することで構成されています。この nt サービスへの要求 (wcf 経由) は、多くの場合、タイムアウト (つまり 90 秒以上) になります。(要求は、同じマシン上の asp.net サイトから発信されます。)

15 分間のウォームアップ時間後の値は 127k (3610 kb) で、1 時間経過後の値は 246k (6427 kb) でした。つまり、119k の jitted メソッドの増加です。

サービスが混乱するまでの実行時間はわずか数時間であるため、報告された問題を引き起こしているのはこの動作だけではないと思います。

しかし、私は、この[明らかに]増え続ける数をどのように解釈するかについて、まだ興味があります. 1 時間あたりわずか 3 mb ですが、1 週間あたり 500 mb になります。また、「# of IL Bytes Jitted」がガベージ コレクションの対象かどうかは誰にもわかりませんか?

(この投稿を書くのにかかった 20 分の間に、メソッドの数は 33k 増加し、バイト数は最大 300k 増加しました。)

明確化
最初に言及すべきだったこと... ;)

  • アプリドメインを作成、ロード、またはアンロードするコードはありません。
  • 何も出力せず、C# 3 を使用しているため、動的オブジェクトはありません。
  • NHibernate と AutoMapper を使用しており、どちらもリフレクションを使用して目標を解決しています。ただし、これらのライブラリは適切に動作し、この動作を引き起こすことはないと思います。(どのメソッドが jit されているかを確認できるツールはありますか?)

変更点

  • コード行数と jitted メソッド数の比較を削除します。Oded が指摘しているように、カウンターには .NET Framework 内のメソッドも含まれています。
4

2 に答える 2

3

プロセスがコードをジッティングし続ける理由はいくつか考えられます。特定の AppDomains にアセンブリを読み込む場合、別の AppDomain にアセンブリを読み込むと、同じメソッドが再適用されます (アセンブリがドメイン ニュートラルとして読み込まれる場合を除く)。

動的メソッドを生成して実行すると、すべての新しいメソッドがジッティングされます。

ガベージコレクションについて。GC は管理オブジェクト ヒープのみを消去します。Jitted コードは AppDomain のコード ヒープに格納されるため、GC によって収集されません。AppDomain をアンロードすると、そのドメインのコード ヒープが削除されます。

この投稿には追加の詳細がありますhttp://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

更新：ツールについて

WinDbg + Sos は、タイプごとにどのメソッドがジットされているかを示します。を使用し!dumpmt -mdます。コマンドを使用して、各 AppDomain に読み込まれているモジュールを確認することもできます!dumpdomain。ただし、探している詳細を見つけるには、おそらく少し掘り下げる必要があります。

于 2010-02-26T13:44:07.537 に答える
1

jit された行数には、フレームワークとサード パーティのライブラリ コードが含まれます。

これは C# や VB.NET の行ではなく、CIL の行であり、さらに多くの行があります。これで不一致を説明するのに十分な場合があります。

于 2010-02-26T13:42:29.957 に答える