Note
この記事は、3 部構成のシリーズに含まれています。 パート 1: TCP/IP パフォーマンスの概要およびパート 3: TCP/IP パフォーマンスの既知の問題を確認できます。
スループットが特定の 基準を下回った場合はパケット キャプチャ ツールを使用してネットワーク トレースを取得し、ネットワークの問題を検出します。
ctsTraffic ツールを使用してネットワーク トレースを分析する
ctsTraffic ツールを使用してネットワーク トレースを分析する方法の例を次に示します。
Note
ネットワーク トレースを実行すると、スループットがさらに低下する可能性があります。
クライアント側とサーバー側の両方で ctsTraffic ツールを実行します。
サーバーで次のコマンドを実行します。
CTStraffic -listen:*クライアントで次のコマンドを実行します。
CTSTraffic -target:<serverip> -consoleverbosity:3 -connections:4 -iterations:10 -connectionfilename:<filename>.csvクライアント側とサーバー側の両方でネットワーク トレースを停止します。
<filename>.csv ファイルを確認します。
- ファイルに NetworkErrors または ProtocolErrors が表示されている場合は、次の手順に進みます。
- エラーが表示されない場合は、ネットワーク トレースを停止して破棄します。 クライアントとサーバーで新しいトレースを収集します。 エラーが発生するまで、手順 1 で接続数 (
-connections:) を増やしてみてください。
<filename>.csv ファイルでエラーのクライアント ソケット番号を見つけ、この番号をフィルターとして適用して、どちらのエンドポイントからも開始されなかったパケット損失、パケット再送信、または TCP リセットを確認します。 この情報が手に入った状態で、ネットワーク チームに問い合わせてください。
パフォーマンス モニターのログを確認する
パフォーマンス モニターログを調べて、次の状況でPacket Received Discardedを見つけます。
- エラーはありますが、パケット キャプチャに問題はありません。
- 元のパケットは宛先に到達しますが、受信側による受信確認 (ACK) がないため、送信者は同じパケットを再送信します。
パケットの破棄は、ネットワーク カード ドライバー、またはプロセッサが受信側で受信パケットを処理できないことが原因である可能性があります。 ネットワーク カード ドライバーが最新であり、 RSS/VMMQ が正しく設定されていることを確認します。 たとえば、SQL Server などのサーバーでより多くの基本プロセッサを使用するには、ベース プロセッサを使用しないように RSS/VMMQ をカスタマイズし、次の物理コアからの処理を開始します。
詳細については、「 Network 関連のパフォーマンス カウンター」を参照してください。
Note
RSS/VMMQ をカスタマイズするのは、トラブルシューティングのためにのみであり、操作を完全に理解している必要があります。