3

次のコマンドを使用して、サーバー上の ASP.NET プロセスのメモリ ダンプを作成しました: .dump /ma mydump.dmp。メモリリークを特定しようとしています。

ローカルの開発用 PC でダンプ ファイルをより詳細に確認したいと考えています。ダンプ ファイルを作成するのと同じマシンでデバッグすることをお勧めします。ただし、一部の開発者はローカルの開発用 PC でダンプ ファイルを分析しているとのことも読みました。最善のアプローチは何ですか？

上記のコマンドを使用してダンプ ファイルを作成すると、W3WP プロセス メモリが約 1.5 倍増加することに気付きました。なんでこれこれ？これはライブサーバーでは避けるべきだと思います。

4

3 に答える 3

1

私は WinDBG の専門家ではありませんが、ASP.NET サイトのダンプ ファイルを分析してStackOverflowException.

ライブ サイトのダンプ ファイルを取得している間 (それが失敗していたので選択の余地がありませんでした)、もともとローカルの開発用 PC でそのダンプ ファイルを分析しようとしましたが、そこから CLR データを読み込もうとしたときに問題が発生しました。その理由は、開発用 PC とサーバーの間で .NET フレームワークの正確なバージョンが異なっていたためです。どちらも .NET 4 でしたが、開発用 PC には、サーバーにはインストールされていない累積的な更新プログラムがいくつかインストールされていたと思います。この不一致のため、 SOS モジュールは単純に読み込みを拒否しました。私は実際に私の調査結果についてブログ記事を書きました。

したがって、質問の一部に答えるには、サーバーから WinDBG を実行する以外に選択肢がない可能性があります。少なくとも、ダンプ ファイルが環境と一致することを確認できます。

于 2012-07-15T20:13:40.943 に答える
1

同じマシンで分析することで、その後の SOS ロードの問題を回避できます。WinDbg と SOS に精通していない限り、混乱しイライラするでしょう。

分析のために別のマシンを使用する必要がある場合は、このブログ投稿を注意深く読んでください。 -dll-0x80004005-or-what-is-mscordacwks-dll.aspx は、必要なファイルをソース マシン (ダンプがキャプチャされる場所) からターゲット マシン (WinDbg を起動するマシン) にコピーする方法を示しています。

2 番目の質問については、WinDbg を使用してプロセスに直接アタッチし、.dump コマンドを使用してダンプをキャプチャすると、残念ながらターゲット プロセスが変更されます。一言で説明するのは簡単ではありません。推奨される方法は、ADPlus.exe または Debug Diag を使用することです。SysInternals の procdump の方が優れています。これらのツールはダンプ キャプチャ用に設計されており、ターゲット プロセスへの影響は最小限です。

アンマネージ ライブラリからのメモリ リークについては、Debug Diag のメモリ リーク ルールを使用する必要があります。マネージ メモリ リークの場合は、メモリ使用量が多いときにハング ダンプを簡単に取得できます。

于 2012-07-16T03:00:41.777 に答える
0

開発マシンで問題を明らかにするのが難しい場合を除いて、実際のマシンでデバッグする必要はありません。

プライベートシンボルを含むpdbがある限り、シンボルが解決され、コールスタックが正しく表示され、正しいバージョンの.NETがインストールされている必要があります。

メモリリークを確認するという点では、Gflagsユーザースタックトレースを有効にし、2つの間隔でメモリダンプを取得して、メモリリークを引き起こすアクションの前後のメモリ使用量を比較できるようにする必要があります。後で、gflagsを無効にすることを忘れないでください。

.Netリークで動作する自動メモリ圧力分析スクリプトを備えたサーバーでDebugDiagを実行することもできます。

于 2012-07-15T20:55:07.737 に答える