web-dev-qa-db-ja.com

100%CPUを使用するW3WP.EXE-どこから始めますか?

IIS6で実行されているASP.NET Webアプリは、CPUを最大100%定期的に撃ちます。これらのエピソード中のほぼすべてのCPU使用率を担当するのはW3WPです。 CPUは、数分から1時間以上の間、100%に固定されたままになります。

これはステージングサーバー上にあり、この時点でサイトはテスターから非常に軽いトラフィックのみを取得しています。

サーバーでANTSプロファイラーを実行しましたが、それは啓発的ではありませんでした。

これらのエピソードの原因と、その間ずっとCPUがビジー状態になっているコードをどこから見つけることができますか

54
Herb Caudill
  1. 標準のWindowsパフォーマンスカウンター(多数のGET要求、過剰なネットワークまたはディスクI/Oなど、他の相関アクティビティを探します)。コードおよびperfmonからそれらを読み取ることができます(たとえば、CPU使用率がしきい値を超えた場合にデータ収集をトリガーするため)
  2. カスタムパフォーマンスカウンター(特に、オフボックスリクエストおよび実行時間が不明なその他の呼び出しの時間)
  3. Visual Studio Team TestやWCATなどのツールを使用した負荷テスト
  4. テストするか、IIS 7にアップグレードできる場合は、要求に一定の時間がかかる場合に失敗した要求トレースを構成してトレースを生成できます。
  5. Logparserを使用して、CPUスパイク時に到着したリクエストを確認します
  6. コードレビュー/ウォークスルー(特に、エラーが発生した場合など、適切に終了しない可能性のあるループ、および静的の使用などのロックおよび潜在的なスレッドの問題を探します)
  7. CPUおよびメモリのプロファイリング(実稼働システムでは困難な場合があります)
  8. プロセスエクスプローラー
  9. Windowsリソースモニター
  10. 詳細なエラーログ
  11. 実行時間の詳細を含むカスタムトレースロギング(CPU使用のパフォーマンスカウンターに基づいた、おそらく条件付き)
  12. AppPoolのリサイクル時にエラーが発生していますか?もしそうなら、それは手がかりかもしれません。
36
RickNZ

大した答えではありませんが、古い学校に行ってIISプロセスのイメージスナップショットをキャプチャし、デバッグする必要があります。チェックアウトすることもできます Tess Ferrandez のブログ-彼女はキックMicrosoft **エスカレーションエンジニアであり、彼女のブログはWindows ASP.NETのデバッグに焦点を当てていますが、ブログは一般的なWindowsデバッグに関連しています。 ASP.NETタグ(私がリンクしたもの)を選択すると、類似したアイテムがいくつか表示されます。

12
Michael Bray

CPUが100%に急上昇し、そこに留まっている場合、デッドロックシナリオまたは無限ループが発生している可能性が非常に高くなります。プロファイラーは、無限ループを見つけるのに適した選択肢のようです。ただし、デッドロックの追跡ははるかに困難です。

4
user246874

Process Explorer は、トラブルシューティングのための優れたツールです。高い [〜#〜] cpu [〜#〜] 使用率の問題を見つけるために試すことができます。アプリケーションの動作方法についての洞察を提供します。

Procdump を試してプロセスをダンプし、実際にCPUで何が起こったかを分析することもできます。

4
sky100

また、perfmonカウンターを見てください。 CPU時間の多くが費やされている場所を教えてくれます。使用する最も一般的なカウンターへのリンクは次のとおりです。

1
RockySanders99

大量のデータを出力にダンプする再帰クエリでこれを行いました-すべてが終了し、無限ループが存在しないことを二重にチェックしましたか?

単一のページでそれを絞り込もうとするかもしれません-同じケースでもANTSはあまり役に立たないことがわかりました-私たちがやったことは、サイトを実行してCPUを監視するページをヒットする-CPUを監視する次のページをヒットする-非常に系統的な時間がかかりますが、コードトレースで見つけられない場合は運が悪いかもしれません-

IISログファイルを使用して、疑わしい一連のページを追跡できました-

それが役立つことを願っています!

0
braindice

これはせいぜい推測に過ぎませんが、おそらく開発チームがリリースモードではなくデバッグモードでアプリケーションを構築およびデプロイしている可能性があります。これにより、.pdbファイルが発生します。これが意味するのは、システムの実行中にアプリケーションがシステム状態とデバッグ情報を収集するために追加のリソースを消費し、より多くのプロセッサー使用率が発生することです。

したがって、リリースモードでビルドおよびデプロイしていることを確認するのに十分簡単です。

0
CShark