レポート › トラブルシューティング › 一般的なトラブルシューティング › SRT のスパイクと観測数の減少の原因の究明

SRT のスパイクと観測数の減少の原因の究明

まず、サーバ上の別のアプリケーションがアクティブかどうかを判断します。

1. ［エンジニアリング］ページをクリックします。
2. 任意の［レスポンス時間］ビューから以下の設定を選択します。
   • アプリケーション -- すべて
   • サーバ -- サーバの名前を選択します。
   • ネットワーク セット -- すべて
3. このサーバによって監視されているすべてのアプリケーションを表示するには、［レスポンス時間構成］ビューのヘッダにある青いハイパーテキストのアプリケーションをクリックします。

   

   別のアプリケーションが結果のパフォーマンス マップに表示された場合、以下の手順を繰り返し、パフォーマンスの問題の原因がそのアプリケーションかどうかを特定します。

   特定のアプリケーションの観測数が、パフォーマンスの問題が報告されたのと同時に増加しているかどうかが重要です。

4. 他のアプリケーションが結果のパフォーマンス マップに表示されていない場合は、左向きの矢印を使用して［エンジニアリング］ページに戻ります。 水平メニューにある［トレンド］をクリックし、このパフォーマンス イベントが過去数週間および数か月にわたり何らかのパターンを示しているかを確認します。 パターンが表示される場合は、突出した反復日時の問題の特定の時間でプロトコル アナライザを使用し、問題の原因となったアプリケーションを特定します。

   サーバ上でプライマリ アプリケーションの問題を生じさせるアプリケーションの例は以下のとおりです。

   • 夜間に実行されたバックアップ
   • ウィルス対策ソフトウェアへのアップグレード
   • サーバ容量またはパフォーマンスを測定するために他のチームによって使用されるエージェント

   バックアップ処理は通常、バックアップ ソフトウェア エージェントを通じて定時にスケジュール設定されます。 そのため、［トレンド］ビューには、24 時間周期、24 時間おき、またはその他バックアップ スケジュールによる周期と同時にサーバ レスポンス時間の周期的なスパイクを示すパターンが表示されます。

   ウィルス対策定義へのアップグレードは、通常、週単位で、または「必要に応じて」緊急時に実行されます。 自動更新リリース スケジュールを決定するには、ウィルス対策ソフトウェア ベンダーまたはデスクトップ/セキュリティ チーム、あるいはその両方に相談してください。 アプリケーション開発チームがサードパーティ エージェントをインストールしたり、パフォーマンス エージェントをソフトウェアにエンコードする場合もあります。 変更通知を確認して、サーバ上のソフトウェアに加えられた変更がパフォーマンスの問題が始まる直前に行われたものかどうかを判断します。

サーバ/アプリケーション サービスの信頼性が失われたかどうかを判断します。

1. サーバ レスポンス時間が承認済みの値を超えた場合、管理コンソール にしきい値を設定して調査を開始します。 管理コンソール は、自動的に CPU やメモリ使用率などの関連情報を収集します。
2. サーバ システム ログの確認は、アプリケーションの安定性に影響している可能性のあるエラーやその他のイベントを明らかにできます。
3. サーバに面するスイッチ ポートおよびサーバ NIC を確認し、以下のテーブルから二重化および速度設定が正しく設定され、エラーがないようにします。