58

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

これはステージング サーバー上にあり、この時点ではテスターからのトラフィックはごくわずかです。

サーバーでANTSプロファイラーを実行していますが、それは理解できません.

これらのエピソードの原因と、その間ずっと CPU をビジー状態にしているコードは何かを突き止めるにはどうすればよいでしょうか?

4

9 に答える 9

38
  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 のリサイクル時にエラーが発生していますか? もしそうなら、それは手がかりになるかもしれません。
于 2010-01-13T09:59:25.207 に答える
12

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

于 2010-01-12T21:52:22.720 に答える
4

Process Explorerは、トラブルシューティングのための優れたツールです。CPU使用率が高い問題を見つけるために試すことができます。これにより、アプリケーションがどのように機能するかについての洞察が得られます。

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

于 2010-01-13T00:35:38.870 に答える
4

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

于 2010-01-12T21:50:24.300 に答える
1

また、perfmon カウンターを見てください。彼らは、そのCPU時間がどこで費やされているかを教えてくれます。使用する最も一般的なカウンターへのリンクを次に示します。

于 2010-01-12T22:13:54.877 に答える
0

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

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

于 2016-12-30T19:09:27.337 に答える
0

これは、大量のデータを出力にダンプする再帰クエリで発生しました。すべてが終了し、無限ループが存在しないことを再確認しましたか?

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

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

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

于 2010-01-12T21:46:07.533 に答える
-1

これは非常に古い投稿ですが、これもよくある問題です。提案された方法はすべて非常に優れていますが、常にプロセスを指し示します。サイトに問題があることはすでにわかっている可能性がたくさんありますが、特定のページが処理に多くの時間を費やしていることを知りたいだけです。私の意見では、最も正確でシンプルなツールは IIS そのものです。

  1. IIS の左側のペインでサーバーをクリックするだけです。
  2. メイン ペインで [ワーカー プロセス] をクリックします。どのアプリケーション プールが CPU を大量に消費しているかは既に確認できます。
  3. この行をダブルクリックして (最後に [すべて表示] をクリックして更新します)、このプールで CPU 時間を消費しすぎているページ ([経過時間] 列) を確認します。
于 2017-09-12T14:44:26.373 に答える
-2

読み込みに時間がかかるページを特定した場合は、SharePoint の開発者ダッシュボードを使用して、どのコンポーネントに時間がかかるかを確認します。

于 2012-10-26T14:00:19.950 に答える