3

実行中の .Net Web サイトでは、4.45 GB 以上の大量のプライベート バイトが使用されています。これは複数の Web サーバーで発生していますが、パターンはないようです。

他のいくつかの回答と、もちろんTess Ferrandez のブログの助けを借りて、 DebugDiagと WinDbg ( Win8 SDKの一部)を使用して、すでに多くの情報を取得しています。

  • 3 GB を超えて消費している割り当ては 1 つだけであることがわかっています。 ここに画像の説明を入力

  • それがネイティブ メモリであることはわかっています。 ここに画像の説明を入力

  • ヒープ 1 に割り当てられていることがわかっています。 ここに画像の説明を入力

ここから先は行き詰まります。推奨されるコマンド (!heap -stat -h、!heap -flt s、および !heap -p -a) もここにありますが、この動作の原因に関する情報は提供されません。

誰もこれを見たことがありますか？nativerd (IIS のネイティブ コード構成リーダー) が暴走する原因を確認する他の方法やコマンドはありますか?

4

3 に答える 3

0

私はDebugDiagの初心者ですが、次のステップでは、DebugDiagによってモジュールレポートで提供されるコールスタックのサンプルを調べて、これらの割り当ての原因を確認する必要があると思います。スクリーンショットから、問題のある関数はすでにクリックされているように見えます。DebugDiagレポートのそのセクションには何が表示されますか？また、それが単一の割り当てであることをどのように知っていますか？

于 2012-11-18T12:00:12.943 に答える
0

windbgにsosdllをロードします。

windbgで！dumpheap-statを試してください。これにより、ヒープ内のすべてのオブジェクトが返されます。

ヒープをトラバースして、どのオブジェクトがより多く作成されているかを確認し、そのオブジェクトがまだメモリ内にある必要があるかどうか、またはずっと前にガベージコレクションする必要があるかどうかを分析します。

そのようなオブジェクトを収集して！gcrootを実行すると、ガベージコレクションからオブジェクトを保持している親オブジェクトを確認できます。これは、メモリリークを絞り込むのに役立ちます。

最も一般的なメモリリークは、.netでのイベントの使用が原因で発生します。クラスAはクラスBのイベントにサブスクライブします。クラスBがガベージコレクションされていない限り、オブジェクトAは引き続きメモリに存在します。

アップデート：

ネイティブメモリリークの場合は、コードベースで_CrtDumpMemoryLeaksを使用 します。Visual Studioを使用している場合、メモリをリークするブロックが出力ウィンドウに表示されます

Glowcodeを使用すると、ネイティブメモリリークを検出することもできます。

于 2012-11-01T14:48:32.733 に答える
0

1 つの巨大な割り当てであるため、Windbg を使用してブレークを設定し、コール スタックを調べることができます。 このような休憩を設定する方法については、こちらの回答を参照してください。これは 32 ビット用です。おそらく 64 ビット用に調整する必要があります。

于 2012-11-05T08:21:35.050 に答える