13

タスク マネージャーによると 130MB のメモリを保持するプロセスがあり、dotTrace によると 11MB のライブ .NET オブジェクトしかないので、他の 120MB で何が起こっているのだろうか??

プロセスに読み込まれたアセンブリとネイティブ DLL を一覧表示し、処理中のイメージのサイズを取得し、アセンブリごとに JIT されたメソッドのメモリ フットプリントを測定するツールが必要です。

SysInternal のListDllsは、その役割の一部を果たします。ただし、JITed コードのサイズは測定されず、生データのみが提供されます。理想的には、これらのデータを分析して集計する UI が必要です。

最近、Visual Studio チームは、ツールPerfViewを使用してそのような分析を行ったことを報告しました。これは、ブログ投稿Visual Studio 11 Beta Performance Part #1のセクション: The Biggest VM Consumer - DLLsに記載されています。PerfView を使用してネイティブ DLL とアセンブリのフットプリントを分析した経験とフィードバックを持っている人はいますか?

ListDllsとPerfViewを除いて、他のツールをお勧めしますか?

わかりました。Simon MourierがアドバイスしたVMMAPは、このタスクにより適したツールのようです。VMMAP は、ワーキング セット メモリの大部分がマネージド スタック (下図の緑色の 113MB) に入ることを示しているため、問題はアンマネージド メモリよりも .NET オブジェクトに関連しています。緑の鋸歯状の曲線は、セッションのロード/アンロードの単なるタイムラインです。いくつかの理由で、私の最初の測定はかなり間違っていました。ここに画像の説明を入力

  • dotTrace は、41MB の .NET オブジェクトが割り当てられていることを示しています。
  • WMMAP では 180MB のワーキング セットが表示されます (タスク マネージャーでも同様の数値が表示されます)。
  • WMMAP は、GC によって割り当てられた 113 MB のマネージド ヒープを示しています。このマネージ ヒープ メモリの 90 MB はワーキング セットにあります。

だから私の計画は次のとおりです。

  1. GC が 41 MB の .NET オブジェクトに 113 MB のマネージド ヒープを割り当てる理由を特定してください。(そのような数値は正常ですか? フラグメンテーションが高いためですか?)
  2. 割り当てられた .NET オブジェクトのこの 41MB セットを縮小する作業を行ってください!
4

3 に答える 3

0

SciTech.NETメモリプロファイラーをお勧めします。このツールは主に、.NETメモリリークの検出やメモリ負荷の高いゾーンの特定など、.NETメモリ使用量のプロファイリングを目的としています。主な用途ではありませんが、ロードされたライブラリごとのJITコードサイズなど、ネイティブメモリの表示も簡単です。この種の情報で、これらの120MBがどこから来ているのかを見つけることができると確信しています。

于 2012-03-23T08:14:45.750 に答える
0

これらの問題には、 RedGate ANTS .NET Developer Bundleを使用します。 Memory Profilerを使用すると、メモリ リーク (ゾンビ オブジェクトなど) を特定し、メモリ使用量のスナップショットを作成できます。その後、2 つのスナップショット間でクラスとインスタンスを比較できます。ツリーでインスタンス参照を追跡し、参照を保持している最上位のオブジェクトを簡単に表示できます。

さらに、パフォーマンス プロファイラーは、ボトルネックと CPU 使用率を特定するためのコード プロファイリングを提供します。

何年もの間、アプリケーションの問題を数分以内に発見するのに大いに役立ちました。

于 2012-03-23T08:55:02.300 に答える