.NETの事後分析にはどのような可能性がありますか(プログラムのクラッシュ後など)?
-
19-08-2019 - |
質問
Windowsサービスとして使用されるC#プログラムがあるとします。サービスが暴走し、CPUやメモリを狂ったように消費しているとします。本番システムであるため、すぐに再起動する必要があります。そのため、ランタイム情報を収集する時間はあまりありません。タスクマネージャの概要をご覧ください...それですべてです。
その後は、log4netログファイルと、事後分析用のWindowsイベントログしかありません。
問題の理由を見つけたとします。他の誰かがそれを修正し、おそらくプログラマーがさらにログを追加するので、次回同様の問題をより早く見つけることができます。それにもかかわらず、私はまだログファイルの品質に依存しており、次回問題が何らかの形でログに記録されることを期待しています。
死後分析を行う他の方法もありますか?たぶん、スレッドダンプ(javaのような)、メモリダンプ、または事後分析に役立つその他の何かのようなものでしょうか。おそらく、組み込みの.NETフレームワークツールが役立ちますか?
実際のプロジェクトの経験と、このメンテナンスの質問にどのように取り組むかについて非常に興味があります。これはほとんどのプログラマにとって非常に現実的だと思います。
解決
MarcがWinDbg + SoSを使用すると多くの問題をデバッグできるため、Visual Studioで実際に対処することはできません。いくつかの優れたチュートリアルがありますこのブログ。
メモリの問題については、Perfmonの.NETパフォーマンスカウンターもご覧ください。オブジェクトの場所(世代)と、ガベージコレクションに費やされる時間を確認できます。それはあなたにいくつかの有用な情報を与えるはずです。オブジェクトが収集されない理由を知りたい場合は、WinDbgとSoSを使用します。簡単なセッションを順を追って説明する手順は次のとおりです。
-
!dumpheap -stat
を使用してヒープを検査し、多数のインスタンスを探します。ヒープ上で何が見つかるかについて、おそらくある程度の考えがあるので、通常とは異なるものがあれば、それを調べてください。 -
ランダムなインスタンスを選択し、インスタンスのアドレスで
!gcroot
を実行します。これにより、オブジェクトが収集されない理由がわかります。 -
繰り返し
イベントを必要以上に長く維持する可能性のある候補は、イベント、静的、ファイナライザキューなどです。
この質問では、WinDbgに関するその他の情報をご覧ください。
他のヒント
.NETでクラッシュダンプを実行し、windbg / sos(およびsosassist)でクラッシュダンプを確認できます。単純ではありませんが、機能します。しかし、かなり筋金入りです。 <!> quot; + windbg + .NET <!> quot;で検索します。興味深いものになるはずです。
それ以外-リソースカウンター?ログファイル?あなたが見るかもしれない多くのものは、かなり簡単に有効にできます。
残念ながら、私はこれをかなりしなければなりませんでした-私が遭遇した最高のツールは、sdkに付属するcordbgです(.netバージョンには正しいバージョンが必要です)。 http://msdn.microsoft.com/en-us/library/a6zb7c8d。詳細については、aspx 。
cordbg(a <!> lt; [pid] <!> gt;)で実行中のプロセスに接続し、実行中の各スレッドに接続(t <!> lt; [tid] <!> gt;)してからダンプ各スレッドのスタック(w)。
小さなvbスクリプトでこのタスクを自動化してからファイルにダンプすると、このツールを何度も実行して、出力をファイルにキャプチャできます。すべてのスレッドスタックを比較すると、アプリケーションが時間を費やしている場所について非常に良いアイデアが得られます。
特にダンプの自動化に関するこのアプローチの良い点は、すべての情報を非常に迅速に取得し、最短時間でプロセスを再起動できることです。
WinDbgとSOSを使用した事後分析のための優れたリソースはTess Ferrandezの主題に関する一連のブログエントリ。
編集:リンクが更新されました
プロセスがまだ実行中の場合、 Managed Stack Explorer に対して、それが何をしているかの簡単なスナップショットを取得します。明示的にインストールせずにこれを実行できます。
それ以外は、フルダンプ+ windbg + SOSが最も多くの情報を提供しますが、それを取得するのは簡単ではありません。