3

そのため、ホスティング プロバイダーは最近、テスト サーバーをある環境から別の仮想化環境に移動しました。移動後、テスト環境でいくつかの処理が非常に遅くなりました。

たとえば、リモート デスクトップへのログインは遅く、リモート デスクトップを使用せず、ログインするだけでした。また、通常は風のように実行される一部の asp.net アプリケーションが、亀のように実行されるようになりました。この速度低下の原因について多くの議論を重ねた後、私は実際の問題を調査し始めました。

最後に興味深い発見があったのは、テスト サーバーに dotTrace をインストールしたときです。パフォーマンスが悪いとわかっていたページを実行すると、問題のあるページの作業を実行したスレッドについて、次の (高レベルの) 結果が得られました。

Real/wall time: 45538 ms
Thread time:    375 ms

私の知る限り、これは、スレッドが実行されずに非常に長い時間を費やしていることを意味します。私の持論は、仮想環境が私の​​サーバーよりも他のサーバーの動作を優先しているというものです。それが原因でしょうか？あなたの考えは何ですか？

注: 実際のトレースなどの詳細が必要な場合は、お問い合わせいただければ問題なく配布いたします。

編集：詳細！トレースで最も高価な呼び出しは次のとおりです。

KeyInfoX509Data.ctor(X509Certificate, X509IncludeOption)
への 1 回の呼び出し: 30014 ミリ秒 SignedXml.ComputeSignature への 1 回の呼び出し: 15045 ミリ秒

トレースの詳細

4

2 に答える 2

2

私にとって、その不一致は IO 待機の問題の悲鳴です。ディスクまたはネットワークのいずれかである可能性が最も高いですが、CPU も私を驚かせることはありません。

特に証明書の読み取りにあるように見えるので、ディスクまたはネットワークのいずれかで貪欲になっている別の VM/サービスがあるかどうかを調べます。大きなファイルや頻繁にアクセスされるデータベースを絶え間なくダウンロードしていることが根本的な原因である可能性があります。

確かに、ハードウェアを共有するすべての VM で対応するアクティビティを確認する必要があります。また、場合によっては、テスト ボックスに到達するネットワーク トレースと、テスト ボックスから外部に到達するネットワーク トレースを確認する必要があります。これはおそらく ISP だけができることです (これは基本的に顧客間の相互作用の問題であるため)。

VM サーバーとハードウェアによっては、調整可能な設定である場合とそうでない場合があります。そうでない場合は、どうすることもできない可能性があります。

いずれにせよ、私はあなたの理論に同意します。アプリケーションの問題ではなく、プロバイダーの問題である可能性が高いです。もしあなたが ISP に何らかの影響力を持っているなら、プロバイダーの変更を解決したり調査したりするために、私はそれを彼らに返します. それをハッキングするコストは、ハードウェアを専用にするか、必要なサービスを提供できるプロバイダーを使用するだけで、大幅に小さくなります.

于 2009-12-21T16:45:55.740 に答える
0

したがって、セキュリティ/ネットワーク/DNSの問題であることが判明しました。サーバー上の DNS 登録の 1 つが正しくありませんでした。これにより、AD サーバーを検索しようとしたときに、間違った IP が返されました。その後、AD 情報を要求するときにタイムアウトが発生し、他の問題が再び発生しました。これらの問題はすべて、特定のページをリクエストするときに長い一時停止として表示されるだけでした。

于 2009-12-23T13:19:16.237 に答える