私の開発チームは現在ASP.NET 3.5/4.0を使用しており、サイトはIIS 7.5で実行されています。最近、Outの原因となる問題(週に1回程度)が発生していますASP.NETアプリケーションでスローされるメモリ例外の1つです。「解決策」は、Webサイトでアプリケーションプールを再起動することです。「解決策」は、ほとんど解決策ではないため、アプリケーションプールを実行し続けているだけの包帯です。合理的な状態にあります。一部のアプリケーションまたは多くのアプリケーションがメモリリークを起こしており、時間の経過とともに蓄積されてメモリ不足の例外が発生しているようです。IISアプリケーションプールでは、バンドエイドを適用し続けるのではなく、プログラムを修正するためにメモリリークを検出する方法を知っています。ASP.NETのメモリリークを検出してログに記録できるツールはありますかアプリケーション?
また、TelerikのRADコントロールを使用するように切り替えたときに、この問題の多くが実際に発生し始めました。他の誰かがこれらのコントロールを使用してこれに類似した問題を抱えていませんか?
おかげで、
アーロン
以前に別の質問への回答としてこのガイドを投稿しましたが、その質問と私の回答は削除されたようです。心臓の弱い人のためではありません:
アプリケーションがしばらく実行されている場合は、adplusを使用してプロセスのメモリダンプをキャプチャします(Process Explorerなどを使用して、ダンプする正しいプロセスIDを見つけると便利です)。
ADPLUS -hang -p <process id> -o .
これにより、メモリダンプを含むディレクトリが作成されます。これでwindbgを使用して、ダンプファイルを開くことができます([ファイル]-> [クラッシュダンプを開く...])。
アンマネージコードの喜びが表示されます。ただし、.NETコードを理解するSon of Strikeと呼ばれるものを使用して、割り当てられているオブジェクトを確認します。最初にSOSをロードします。
.loadby sos mscorwks
そして、マネージヒープを調べるように要求します。
!dumpheap -stat
これにより、一般に大量の出力が生成されますが、インスタンス数と消費されているメモリの量をタイプ別に示す2つの列があります。多くのタイプ(Stringなど)が予想されるタイプですが、たとえば、独自のタイプのインスタンスが何千もある場合、これらのオブジェクトが何らかの形でリークしている可能性があります。過去に私が気付いたのは、オブジェクトのイベントハンドラーをアプリケーションの静的イベントにフックすることです。そのイベントには、これらのオブジェクトのすべてへのライブ参照があります。
私はこれの大部分がどのように機能するか思い出せず、一般的にこれを参照します SOSのチートシート
Tess Ferrandezには 良いブログ があり、アンマネージドデバッガーを使用した.NETデバッグがカバーされていることがあります。
例えば。 昨年5月の投稿 、デフォルト以外のコンストラクタでXmlSerializer
sを使用した場合の潜在的な問題の詳細。
そこには多くのメモリプロファイラがあります。
人気のある1つは DotTrace で、もう1つは ANTSメモリプロファイラー です。どちらも商用製品です。
Asp.net webプロファイラ を使用することもできます。これは無料のツールであり、アプリケーションの実行中に情報がメモリに保存されているのを確認できます。
これにより、asp.netキャッシュを分析し、現在のすべてのセッションとアプリケーションの状態の内容を表示できます。
サードパーティのツールにお金を払うことなく、非常に低いレベルまで下げることができます。これは心臓の弱い人のためではありません。
ASPの.Netメモリリークは、持続するものに限定されます。アプリケーションの状態と、それほどではないがセッションの状態。
これらの領域内で機能するものはすべて、最初にチェックします。
また、任意のクラスの静的オブジェクト、特にリストやその他の種類のオブジェクト。