TCP/IP パフォーマンスの既知の問題

Note

この記事は、3 部構成のシリーズに含まれています。 「パート 1: TCP/IP パフォーマンスの概要およびパート 2: ネットワークの問題の基になる TCP/IP パフォーマンスを確認できます。

この記事では、次の TCP/IP パフォーマンスの問題について説明します。

• 高遅延および高帯域幅ネットワークのスループットが遅い
• 低遅延および高帯域幅ネットワークのスループットが遅い
• 基になるネットワークの問題

待機時間が長く帯域幅ネットワークのスループット速度が遅い

異なるサイトにある 2 台のサーバーが、待機時間の長いネットワーク経由で接続されています。 ctsTraffic ツールで測定されるスループットは、ベースラインよりも低くなります。

これは、どちらのサーバーでも TCP ウィンドウ スケール オプションが有効になっていないためです。 WINDOWS コマンド プロンプトまたは Windows PowerShell を使用して、TCP 受信ウィンドウの自動チューニング レベルを設定してオプションを有効にします。

コマンド プロンプトを使用して自動チューニング レベルを有効にする

次のコマンドを実行します。

netsh int tcp set global autotuninglevel=normal 

自動チューニング レベルが有効になっているかどうかを確認するには、次のコマンドを使用します。

netsh int tcp show global

PowerShell を使用して自動設定レベルを有効にする

次のコマンドレットを実行します。

Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

自動チューニング レベルが有効になっているかどうかを確認するには、次のコマンドレットを使用します。

Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*

Note

受信ウィンドウの自動チューニングには、無効、高度制限、制限付き、標準、試験段階の 5 つのレベルがあります。 自動チューニングがスループットに与える影響の詳細については、「 パフォーマンス チューニング ネットワーク アダプター」を参照してください。

待機時間が短く、帯域幅が広いネットワークでのスループット速度が遅い

待機時間が短く、帯域幅が広い同じネットワーク上に 2 台のサーバーが接続されています。 ctsTraffic ツールを使用してベースラインを作成するか、TCP パフォーマンスをテストすると、マルチコア CPU サーバーでは CPU 0 のみが急増します。

この問題は、受信側スケーリング (RSS) または仮想マシン キュー (VMQ) 機能が有効になっていないか、正しく構成されていないために発生します。 物理マシンがハイパーバイザーである場合は、VMQ を使用します。 そうでない場合は、オペレーティング システム (OS) とネットワーク カードの両方で RSS を有効にします。

Note

ワイヤレス ネットワーク カードは、RSS または VMQ 機能をサポートしていません。

OS の RSS を有効にする

コマンド プロンプトまたは PowerShell を使用して、次のように RSS を有効にします。

コマンド プロンプト: netsh int tcp set global rss=enabled

PowerShell: Set-NetAdapterRss -Name <interface name> -Enabled $True

ネットワーク カードの RSS を有効にする

まず、RSS 機能が有効になっているかどうかを確認します。 次のコマンドレットを使用して、関連する構成のネットワーク カードの詳細プロパティを確認します。

Get-NetAdapterAdvancedProperty | Where-Object -property RegistryKeyword -Like *rss* | format-table -AutoSize

Note

高度なプロパティを変更すると、ネットワーク接続が中断または失われる可能性があります。 変更を行う前に、NIC ベンダーのドキュメントを参照してください。

ネットワーク カードの RSS を有効にするには、次の手順に従います。

1. ncpa.cplを実行して、Network 接続を開きます。
2. ターゲット接続を右クリックし、 Properties>Configure を選択します。
3. [Advanced] タブの [プロパティの一覧で Receive Side Scaling を探し、Value を Enable に設定します。
4. [OK] を選択します。

RSS は、PowerShell コマンドレットを使用して有効にすることもできます。

Set-NetAdapterAdvancedProperty -Name <Interface name> -RegistryKeyword *RSS -RegistryValue 1

基になるネットワークの問題

このセクションでは、スループット ベースラインを測定したり、スループットの問題のトラブルシューティングを行ったりするときに、基になるネットワークの問題を確認する方法について説明します。

パケット レベルのログ分析を取得するには、ネットワーク パケット キャプチャ ツール (Microsoft ネットワーク モニター、Wireshark、ctsTraffic など) を使用して、基になるネットワークの問題を確認します。

ネットワーク パケット キャプチャ ツールを使用してログを取得する手順

1. Microsoft ネットワーク モニターまたは Wireshark でログ記録を開始し、両方のエンドポイントでトラフィックをキャプチャします。 次のように Windows 組み込みのキャプチャ ツールを使用することもできます。

   1. 管理者としてコマンド プロンプトを開きます。

   2. 次のコマンドを実行します。

      NETSH TRACE START CAPTURE=YES REPORT=DISABLED TRACEFILE=<FILEPATH>.ETL MAXSIZE=512
      

      Note

      netsh trace コマンドの使用中に、複数のキャプチャが必要になる場合があります。

2. CTStraffic.exe ツールを実行して、 .csv ファイルを生成します。

3. ログ記録を停止します。 Windows 組み込みキャプチャ ツールの場合は、管理者としてコマンド プロンプトに「 NETSH TRACE STOP 」と入力します。

キャプチャ ファイルを分析する

フィルター処理された結果を分析する方法を示す例を次に示します。 このシナリオでは、ctsTraffic ツールはプッシュ パターン (既定のパターン) を使用します。つまり、パケットはクライアントからサーバーに送信されます。

1. Microsoft ネットワーク モニターでキャプチャ ファイルを開きます。

2. Property.TCPRetransmit==1 && tcp.Port==4444 フィルターを使用してネットワーク トレースをフィルター処理し、再送信パケットを見つけます。 パケット再送信とは、送信側からの指定された TCP シーケンスの TCP 受信確認が受信されないという意味です。

   Note

   ETL ファイルを分析するには、 Tools>Options>Parser Profiles>Windows>Set As Active>OK に移動します。

   

   スクリーンショットに示すように、フレーム #441 は 2 回再送信されます。つまり、送信者によって 3 回送信されます。 同じ TCP シーケンス番号 (2278877548) を使用して、このフレームを識別します。

3. Frame の詳細でSequenceNumberを右クリックし選択した値を選択してフィルターを表示します。

   

4. 次のように "//" を追加して、前のフィルターを無効にします。

   

5. 適用を選択します。 このシーケンス番号を持つ完全な TCP シーケンスは、次のように表示されます。

   

   この結果は、元のフレーム #441 がサーバーによって受信されず、送信者によって再送信されることを示しています。 フレームの再送信は、シーケンスの受信確認が受信されない場合に発生します。 TCP のしくみについては、「 TCP/IP 経由の 3 方向ハンドシェイク および Windows TCP 機能の 説明」を参照してください。 次に、クライアント トレースから TCP.SequenceNumber == <value> シーケンス フィルターをコピーし、サーバー トレースに貼り付けます。

   サーバーでは、次の結果に示すように、特定のシーケンスのパケットが 1 つだけ受信されます。

   

   この結果は、中間ネットワーク デバイス上の送信側から受信側へのパケット損失があることを証明します。 パケットは送信側を離れますが、受信側には到達しません。 これは基になるネットワークの問題であり、ネットワーク管理者が解決する必要があります。

TCP ループバック のパフォーマンス

Windows Server 2019 のリリースでは、以前の Windows リリースに存在していた特定のパフォーマンスのボトルネックに対処するために、TCP/IP ループバック処理モデルが変更されました。 このセクションでは、TCP/IP ループバック処理の動作を変更するために使用できる構成オプションについて説明します。

構成パラメーターは、netsh 構成ツールを使用して使用できます。 各設定は、IPv4 と IPv6 に対して個別に設定できます。 既定値は、Windows のバージョンによって異なる場合があります。

Note

汎用 Windows コンピューターでは、既定値を変更しないでください。

アプリケーション開発者が、ループバック データ パスがアプリケーションのパフォーマンス不足の根本原因であると判断した場合は、次のコマンドを使用して、アプリケーションの個々のニーズに合わせて構成を調整できます。

netsh int ipv6|ipv4 set gl loopbackexecutionmode=adaptive|inline|worker
netsh int ipv6|ipv4 set gl loopbackworkercount=<value>
netsh int ipv6|ipv4 set gl loopbacklargemtu=enable|disable

説明

Loopbackexecutionmode
Worker

このモードでは、パケットは送信側でキューに入れられ、受信側のワーカー スレッドによって処理されます。 このモードでは、待機時間よりもスループットが優先されます。

Inline

このモードでは、送信側側と受信側側の両方でアプリケーション スレッドのコンテキストで処理が行われます。 このモードでは、スループットよりも待機時間が優先されます。

Adaptive

データ フローの最初のパケットはインラインで処理され、次にパケットはワーカー スレッドに遅延されます。 このモードでは、待機時間とスループットのバランスを取ろうとします。

Loopbackworkercount

使用されているワーカー スレッドの数を構成できます。

Loopbacklargemtu

大規模な MTU の使用を構成できます。これを有効にする必要があります。