8

私はいくつかのメモリ使用量の問題に取り組もうとしています。全体として、私のアプリケーションはいくつかのデータ値を収集し、C1 WPFチャートとデータグリッドを使用してそれらを視覚化し、最終的にすべてをPDFレポートに入れます。

YourKitを使用してプロセスをプロファイリングするCLRヒープサイズが約120MB（これはすべて問題ありません）であるのに対し、プロセスメモリサイズは約580MBであるという状況に直面しています。これは、実際のCLRヒープサイズの約5倍のメモリ消費量です。私のCLRピークサイズは220MBでしたが、プロセスメモリの割り当ては710MBでした。

オブジェクトのヒープやスタックなどにオーバーヘッドが必要であることはよく知っています。Java JVMでは、私が慣れている典型的な要因は約1.5倍でした。

この過剰なメモリオーバーヘッドはどのように説明できますか？プロセスは、空きヒープスペースを割り当てるだけですか？はいの場合、これは710MBと220MBを説明していますか？

4

2 に答える 2

14

ここにいくつかの追加の注意事項があります。「CLRヒープサイズ」の意味が正確にはわかりませんが。使用している .NET ランタイムに応じて、CLR が使用する 8 つまたは 9 つの異なるヒープがあります。そのため、ヒープ サイズと VM サイズに表示されるメモリは、いくつかの違いを説明しています。

  1. ローダー ヒープ: CLR 構造体と型システムが含まれています
  2. 高頻度ヒープ: statics、MethodTables、FieldDescs、インターフェイス マップ
  3. 低頻度ヒープ: EEClass、ClassLoader、およびルックアップ テーブル
  4. スタブ ヒープ: CAS、COM ラッパー、P/Invoke のスタブ
  5. 大きなオブジェクト ヒープ: 85k バイト以上を必要とするメモリ割り当て
  6. GC ヒープ: アプリ専用のユーザー割り当てヒープ メモリ
  7. JIT コード ヒープ: mscoreee (実行エンジン) によって割り当てられたメモリとマネージ コード用の JIT コンパイラ
  8. プロセス/ベース ヒープ: 相互運用/管理されていない割り当て、ネイティブ メモリなど
  9. .NET 5 で追加:固定オブジェクト ヒープ (POH)

過度のメモリ使用を引き起こす可能性がある他の 2 つの項目は、メモリの断片化 (ほとんどの場合、LOH または大きなオブジェクト ヒープで発生します) または多数のスレッドです。

メモリの断片化には多くの原因があり、これを除外する最善の方法は、WinDbg を使用して GC ヒープの各セグメントのセグメント サイズを分析することです。

スレッド数が多い場合、アプリが使用するスレッドごとに 1MB (x86 プロセスの場合) または 4MB (x64 プロセスの場合) のスタック領域が割り当てられます。このメモリは、プロセス/ベース ヒープに配置されます。したがって、100 個のスレッドがある場合、最大 100MB/400MB のメモリ使用量を追加できます。

HTH

于 2012-08-22T14:54:25.970 に答える
2

マネージ ヒープの合計サイズが、アプリケーションで使用されるプライベート バイトよりも大幅に小さい場合は、アンマネージ メモリを割り当てており、(おそらく) 適切に破棄していない可能性があります。IDisposable を実装するグラフィック オブジェクト、ストリーム、およびその他のオブジェクトは、管理されていないリソースがクリーンアップされるようDispose()に、スコープ外に出る前、またはステートメント内に配置される前にメソッドを呼び出す必要があります。using(){}ANTS Memory Profiler などのツールを使用すると、メモリがどのように割り当てられているか、どのオブジェクトが IDisposable を実装しているかを確認できます。

于 2012-04-12T12:58:31.363 に答える