管理されたプロセスが大量のメモリを使用している理由を調べています。GC.Collect(3)実際のメモリ割り当てに集中できるように、WinDbgから実行する方法はありますか?
Roger Lipscombe
質問する
5605 次
4 に答える
5
WinDbg から .NET ガベージ コレクションを実行する方法はないと思いますが、その必要もないと思います。
ヒープにあるものの種類を調べる方法については、Rico Mariani の Performance Tidbits - Tracking down managed memory leaks (how to find a GC leak) を参照してください。
役立つ可能性のあるその他のリンク:
于 2008-12-02T16:17:29.067 に答える
3
WinDbg から GC をトリガーできるとは思えません。
メモリ割り当ての追跡に頼るようになった便利なツールを次に示します。
- SOSEX -- SOS を補完するための WinDbg の拡張機能で、!dumpgen を追加して特定の世代からオブジェクトをダンプします (LOH と Gen 2 にあるものを把握するのに最適です)。物体。
- .Net Memory Profiler -- これはインタラクティブに実行する場合に非常に便利なツールですが、ダンプ ファイルからロードするオプションも含まれています。これにより、メモリ使用量を追跡するかなり直感的な方法が得られます。簡単に 250 米ドルの価値がありますが、14 日間の評価もあります。
于 2008-12-02T16:35:26.283 に答える
2
WinDBGは、何よりもまずWin32/カーネルデバッガです。したがって、 mDBGなどのマネージデバッガーの1つを試してみることをお勧めします。しかし、以前はMSFTの.NETデバッグサポートを行っていたので、メモリリークのトラブルシューティングにそのようなものは必要ありませんでした。
于 2008-12-02T16:46:36.637 に答える
0
ロジャーさん、メモリ リークが解決していることを願っています。:-)
まず、それが「マネージ メモリ リーク」であることを確認します。つまり、パフォーマンス モニター カウンターを見ると、.NET CLR メモリ -> すべてのヒープ内の # バイトが、同じプロセスのプロセス -> プライベート バイトカウンターと同じ割合で増加していることを意味します。その場合は、上記の手法を使用できます。
そうでない場合は、マネージ コードを実行した結果、ネイティブ リークが発生している可能性があります。私が見た中で最も一般的なのは、.NET アセンブリがプロセスで読み込まれ、アンロードされていないことに関連しています。これは、Perfmon のネイティブ メモリ リークのようです。
DebugDiagで リーク ルールを実行してみて、メモリ レポートにリーク コールスタックとして表示される内容を確認することをお勧めします。
これは、この件に関する別の優れたリソースです。 メモリリークがあります!!! 私は何をしますか？(「どこで」を定義する)
ありがとう、アーロン
于 2009-02-21T22:05:59.627 に答える