はい、新しいビルドでは、各サーバーでランダムな間隔で CPU 使用率が 100% に達します。長時間にわたってサイトが完全に応答しなくなります。これは、さまざまな国のユーザーがサイトにログオンするなどのピーク時に発生します。
perfmom、メモリ プロファイラー、CLR プロファイラー、SQL プロファイラー、Red Gate Ants プロファイラーを調べ、UAT で負荷テストを試みましたが、問題を再現することすらできませんでした。これは、ライブ サイトにアクセスする数千人のユーザーだけがこの問題を引き起こす可能性があることを意味します。
私たちが気づいた 1 つのパターンは、新しいコード (壊れたビルド) では実際に使用するスレッドが著しく少ないということでした。
IOC にもスプリングを使用していますが、これはベッドの評判が良いのでしょうか?
さらに悪いことに、ビジネスへの影響によりライブに展開することができず、追加した新機能のサブセットに問題を絞り込むことができません。
私たちは本当に破滅しました。私たちの命を救うことができるような戦いの傷跡を持っている人はいますか?
答え1
メモリ ダンプを実行し、Sos を使用して WinDdg で分析することをお勧めします。WinDbg なしでは診断できないと思われるいくつかの問題を本番環境で修正しました。
テス・フェルナンデスメモリダンプを分析する方法を学べる素晴らしいブログがあります。
答え2
これは通常、GC での長期間存続する大規模なオブジェクトのクリーンアップによって発生します (stackoverflowにこの問題がありました。リンクを参照してください。）。キャッシュまたはセッションに大量のオブジェクト コレクションを保存していますか?
また、テストのために本番環境で新しいサーバーを構築して構成することをお勧めします。突然異常が発生し、その理由がわからず、再現できない場合は、コードではなくハードウェアまたは構成に問題があると考えられます。
答え3
これは共有リソースを持つ仮想サーバーですか、それとも物理サーバーですか? 前者の場合は、このサーバーにリソースを専用にすることを検討してください。幸運を祈ります...
答え4
データなしで障害を推測するのは無意味です。確かに、stackoverflow やエンジニアリング チームの誰かが幸運に恵まれるかもしれませんが、それは単にエンジニアリングが悪いだけです。また、すべての推測を試すのにどのくらいの時間がかかるか、また、問題が見つかるかどうかについて計画を立てることはできません。
- あなたがしなければならない再現問題。Jmeter は幅広いため良いスタートを切るのに適していますが、アーキテクチャを知らなければ適切なツールを推奨することはできません。
- ログ記録特にアプリケーション層では必須です。パフォーマンスが遅い場合はIISトレースを有効にすることができますが、Microsoftの愚か者たちは、遅いときにパイプラインフロー全体をキャプチャできないようにしました。再現するのが難しい場合は、絞り込みに役立つログが本当に必要です。どこ問題は、(ああ、このストアド プロシージャを呼び出すたびに) です。
CPU 使用率が 100% というのは、I/O ではない可能性が高いという意味で少し疑わしいです (データベースが別のボックスである場合、遅いデータベースによって Web サーバーで CPU 使用率が 100% になることはありません)。もっと詳しく調べる必要があります。