問題タブ [debugdiag]

IIS でホストされている .NET アプリケーションからキャプチャされたメモリを含むファイルがいくつかあり.dmpます。これらのファイルを何らかのアナライザーで実行して、アプリケーションによる原因不明の高いメモリ使用率の原因となっているメソッドを特定したいと考えています。

Visual Studio に付属のツールだけでなく、DebugDiag 分析も試しました。メモリ内のオブジェクトのリストを作成することはできますが、どのメソッドがオブジェクトを生成しているかわかりません。

これを理解するのに簡単に役立つアプリケーションを教えてくれる人、または DebugDiag または Visual Studio を使用してこれを行う方法を教えてくれる人はいますか?

私はすでに可能な限り Google にアクセスしましたが、探している答えを見つけることができませんでした。必要であればツールを購入したいと思っていますが、購入したものが実際に私の質問に答えることができるかどうかを確認したいと思います.

私の現在のアプリケーションは、Web 層 - アプリケーション層 - データベースの 3 層で構成されています。

100 人のユーザーでテストしたところ、アプリケーション層の CPU がほぼ 90% に達しているのに対し、Web サーバーとデータベース サーバーは問題なく動作していることがわかりました。

CPU使用率が高い原因となっているコードを特定できません。主にCRUD操作があります。入力を DTO の形式で取得し、それらを (エンティティ フレームワークを使用して) エンティティに転送し、データベースに追加/更新/削除します。Get 操作の場合、データを EF エンティティにフェッチし、それらを DTO に格納してから、DTO をクライアントに送信します。

DebugDiag を使用しようとしましたが、有用な情報を見つけることができませんでした。

サーバーの構成は次のとおりです。

Web サーバー (数量 = 1)プロセッサ Intel Xeon CPU X5675 @3.07 GHz 2.19 GHz

コア数 (仮想) 8

RAM 8GB

オペレーティング システム Windows Server 2012 Standard

プロセッサの種類 64 ビット

インストールされているソフトウェア NET Framework 4.5

アプリケーション サーバー (数量 = 1)プロセッサ Intel Xeon CPU X5675 @3.07 GHz 3.07 GHz

コア数 (仮想) 8

RAM 8GB

オペレーティング システム Windows Server 2012 Standard

プロセッサの種類 64 ビット

インストールされているソフトウェア NET Framework 4.5

DB サーバー (数量 = 1)プロセッサー Intel Xeon CPU E7-4830v2 @ 2.20 GHz 2.19 GHz

コア数 (仮想) 8

RAM 8GB

オペレーティング システム Windows Server 2012 Standard

プロセッサの種類 64 ビット

インストールされているソフトウェア Microsoft SQL Sever 2014

複数のタスクに分割されたプロセスを実行する C# Windows サービスがあります。ほとんどのタスクは、WCF を使用して Web サービスに接続し、データベースに対して作業を実行します。サービスのタスクは複数のスレッドで実行されます。

お客様から、Windows サービスが時々応答しなくなり、再起動する必要があるとのサポート ケースが提出されました。Windows サービスからメモリダンプを取得しました。DebugDiag 2.0を実行して、ダンプ ファイルを分析しました。

DebugDiag レポートの概要に興味深いエントリがありました。

WindowsService.DMP の次のスレッドは HttpWebRequest を作成しようとしていますが、リモート サーバーでの応答を待機していないようです (たとえば、「通信中」ではありません)。これらの要求の 1 つ以上が、使用可能な接続の最大数の少なくとも半分を使用しています。

( 17 18 27 31 32 33 42 ) ブロックされたスレッドの 12.07% (7 スレッド)

多くのスレッドがこの状態にある場合は、多くの場合、スロットリング制限 (つまり、'maxconnection' 設定) を使い果たしたことを示しています。左側のリストの任意のスレッドをクリックして、待機中の WebRequest のスロットリングの詳細を確認します。

必要に応じて、アプリケーション構成ファイルの「maxconnection」パラメーターを変更するか (「<connectionManagement>要素」を参照)、適切な ConnectionLimit プロパティをプログラムで変更することにより (「接続の管理」を参照)、使用可能な接続の数を増やすことができます。

スレッド17にジャンプして、これを見ました：

スレッド 17 - システム ID 4612

エントリ ポイント mscorwks!Thread::intermediateThreadProc 作成時刻 2015 年 9 月 10 日 10:13:14 AM ユーザー モードで費やされた時間 0 日 00:00:00.000 カーネル モードで費やされた時間 0 日 00:00:00.000

このスレッドは HttpWebRequest を作成しようとしていますが、リモート サーバーでの応答を待機していないようです (たとえば、「通信中」ではありません)。これらの要求の 1 つ以上が、使用可能な接続の最大数の少なくとも半分を使用しています。

警告、利用可能な接続の少なくとも半分が使用されています

HttpRequest URI: http://WebServer/MyWebSite/SubDir/MyService.svc ServicePoint - ConnectionLimit:48 CurrentConnections:44

HttpWebRequest オブジェクトはループバック アドレスですが、接続制限が定義されているため (processModel セクションで autoconfig を true に設定するか、connectionManagement セクション内に * エントリを追加することによって) 接続制限がこの Webrequest オブジェクトに適用されます。

.NET コール スタックは次のとおりです。

私はそれが行った推奨事項を見て、それらの調査を開始しました。私の質問は：

DebugDiag で、スレッドがサーバーの応答を待っていないように見えるのはなぜですか?

.NET Reference Sourceを見ると、リクエストは正常に送信されたように見え、サービスは応答を待っているように見えます。

アップデート

通常の呼び出しに割り込むと、以下の Puneet Gupta によって提案されているように、ws2_2 で待機している呼び出しスタックが表示されます。

したがって、通常は Windows ソケットからの応答を待ちます。この場合、他の DebugDiag メッセージで示されているように、スレッドはおそらく接続がリクエストを処理できるようになるのを待っています。

サーバー: Windows 2012r2 Debug Diagnostic Tool v2.1 update 1

デバッガーはアプリケーション プールにアタッチされます。サイトの正しいプールであることを確認しました。プールはクラッシュしますが、ダンプ ファイルは生成されません。

「そのアプリケーション プールを提供するプロセスで一連の障害が発生したため、アプリケーション プール '' は自動的に無効にされています。」

ルールは、アプリケーション プールを参照するように設定されているだけで、最初のチャンスの例外はキャプチャされません。数回削除して再度追加しようとしましたが、ダンプが生成されません。

生成されたデバッグ ログを確認しましたが、これはプールがクラッシュする直前に生成された最後の例外です。

警告: フレーム IP は既知のモジュールにありません。次のフレームは間違っている可能性があります。0x0 0x0 0x0

編集:最初のチャンスの例外に対してダンプが生成されることを追加したかった。2 番目のチャンス、または実際にクラッシュを引き起こしているチャンスを捉えようとする場合にのみ問題になるようです。

編集 2: リクエストごとのデバッグ ログの 1 つからの最後の数行:

例外はこれに関連しています

DebugDiag 2.1.0.7 によって作成されたダンプを分析することにより、.NET 4.6 MVC5 アプリケーションによって引き起こされた CPU の問題をデバッグしようとしています。カスタム .pdb シンボルを読み込んだ後でも、生成されたレポートでスタックトラック情報をまだ取得していないことがわかりました。

レポートに表示されるエラーは次のとおりです。

DebugDiag バージョン 1.2 は .NET 4.0 以降をサポートしていないことに注意してください。DebugDiag 2.1 は .NET 4.6 をサポートしていないのでしょうか?

DebugDiag 2.1 を使用してダンプ ファイルのパフォーマンス分析を実行しようとすると、レポートに次のスタック トレースを含む NullReferenceException が表示されます。

分析中のアプリケーションは .Net 4.5.2 を実行しています。誰にも解決策がありますか？