サーバーを屈服させるASP.NET High CPU

新しいビルドでは、各サーバーでランダムな間隔で100％のCPUスパイクが発生しています。長期間、サイトが完全に応答しなくなります。これは、さまざまな国の人々がサイトにログオンするなどのピーク時に発生します。

perfmom、メモリプロファイラー、CLRプロファイラー、SQLプロファイラー、Red gate antプロファイラーを調べ、UATで負荷テストを試みましたが、問題を再現することもできませんでした。これは、ライブサイトにアクセスした数千のユーザーだけがそれを引き起こすことを意味する可能性があります。

私たちが気づいた1つのパターンは、新しいコード（壊れたビルド）が実際には著しく少ないスレッドを使用することでした。

また、IOCに春を使用しています-これはベッドの評判ですか？

さらに悪いことに、ビジネスへの影響のために展開して展開することはできません。そのため、追加した新機能のサブセットに問題を絞り込むことはできません。

私たちは本当に破壊されました-誰かが私たちに数人の命を救うかもしれない戦いの傷跡を持っていますか？

WinDdgでSosを使用してメモリダンプを実行し、分析することをお勧めします。私は、WinDbgなしではおそらく診断できないプロダクションに関するいくつかの問題を修正しました。

Tess Fernandezには、メモリダンプの分析方法を学ぶことができる素晴らしいブログがあります。

これは通常、GCでの長期間のオブジェクトのクリーンアップが原因で発生します（stackoverflowにこの問題がありました。リンクを参照してください）。大量のオブジェクトコレクションをキャッシュまたはセッションに格納していますか？

GCによる攻撃

また、テスト用に本番環境で新しいサーバーを構築して構成することをお勧めします。ランダムな狂気があり、その理由がわからず、それを再現できない場合は、コードではなくハードウェアまたは構成を指差します。

これは共有リソースを持つ仮想サーバーですか、それとも物理サーバーですか？前者の場合は、このサーバー専用のリソースを確認できます。幸運を...

をcache serverフロントエンドとして使用してみてくださいApache Traffic Server (ATS)。

これは問題を解決しませんが、潜在的に有害な負荷をバックエンドから移動し（フロントエンドにも問題があるかどうかを確認）、バックエンドでの加熱が少なくなるため、それを特定するのに役立つことがあります。何が悪いのかを簡単に確認できます。

データなしで障害を推測しようとしても無意味です。はい、Stackoverflowまたはエンジニアリングチームの誰かが幸運になるかもしれませんが、それは単に悪いエンジニアリングであり、すべての推測を試すのにどれくらいの時間がかかるか、そしてあなたが問題を見つけるかどうかについて計画を立てることはできません。

1. 問題を再現する必要があります。Jmeterは幅が広いので良いスタートですが、アーキテクチャーを知らないと、適切なツールを推奨できません。
2. 特にアプリケーション層でのロギングは必須です。パフォーマンスを遅くするためにIISトレースを有効にすることはできますが、Microsoftのマペットが有効にしたため、パイプラインフロー全体が遅い場合はキャプチャできません。再現が非常に難しい場合は、問題の場所を絞り込むのに役立つログをいくつか用意してください。（ああのように、このストアドプロシージャを呼び出すときはいつでも）。

100％のCPUは、I / Oである可能性が低いという意味で少し疑わしいです（dbが別のボックスである場合、遅いデータベースはWebサーバーで100％のCPUを引き起こすべきではありません）。あなたは家の近くを見る必要があります。