ネットワーク アダプターのパフォーマンス チューニング

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Azure Stack HCI、バージョン 21H2 および 20H2

このトピックの情報を使用して、新しいバージョン以降を実行しているコンピューターのWindows Server 2016を調整します。 ネットワーク アダプターにチューニング オプションが提供されている場合は、これらのオプションを使用して、ネットワークスループットとリソース使用量を最適化できます。

ネットワーク アダプターの正しいチューニング設定は、次の変数によって異なっています。

  • ネットワーク アダプターとその機能セット
  • サーバーが実行するワークロードの種類
  • サーバーのハードウェアとソフトウェアのリソース
  • サーバーのパフォーマンス目標

以下のセクションでは、パフォーマンス チューニング オプションの一部について説明します。

オフロード機能の有効化

ネットワーク アダプターのオフロード機能の調整には、一般的にメリットがあります。 ただし、ネットワーク アダプターは、高スループットでオフロード機能を処理するのに十分な強力な機能ではない可能性があります。

重要

オフロード機能 IPsec タスク オフロードまたは TCP Chimney Offload は使用しない。 これらのテクノロジは、Windows Server 2016非推奨とされており、サーバーとネットワークのパフォーマンスに悪影響を及ぼす可能性があります。 また、これらのテクノロジは、今後 Microsoft ではサポートされない可能性があります。

たとえば、ハードウェア リソースが限られているネットワーク アダプターについて考えます。 その場合、セグメント化オフロード機能を有効にすると、アダプターの最大持続可能なスループットが低下する可能性があります。 ただし、スループットの低下が許容される場合は、セグメント化オフロード機能を有効にする必要があります。

注意

一部のネットワーク アダプターでは、送信パスと受信パスに対してオフロード機能を個別に有効にする必要があります。

Web サーバーの受信側スケーリング (RSS) を有効にする

サーバーの論理プロセッサよりもネットワーク アダプター数が少ない場合、RSS で Web のスケーラビリティとパフォーマンスを改善できます。 すべての Web トラフィックが RSS 対応ネットワーク アダプターを通過している場合、サーバーは異なる CPU 間で異なる接続からの受信 Web 要求を同時に処理できます。

重要

RSS 以外のネットワーク アダプターと RSS 対応のネットワーク アダプターの両方を同じサーバーで使用しないようにします。 RSS およびハイパーテキスト転送プロトコル (HTTP) の負荷分散ロジックにより、RSS 対応でないネットワーク アダプターが、1 つ以上の RSS 対応ネットワーク アダプターを持つサーバー上の Web トラフィックを受け入れる場合、パフォーマンスが著しく低下する可能性があります。 このような場合、RSS 対応ネットワーク アダプターを使用するか、ネットワーク アダプターのプロパティの [詳細プロパティ] タブで RSS を無効にすることをお勧めします。

ネットワーク アダプターが RSS 対応かどうかを判断するには、ネットワーク アダプターのプロパティの [詳細プロパティ] タブの RSS 情報を確認します。

RSS プロファイルと RSS キュー

既定の RSS 定義済みプロファイルはNUMAStaticです。これは、以前のバージョンのサービスで使用Windowsです。 RSS プロファイルの使用を開始する前に、使用可能なプロファイルを確認して、それが有益な場合と、それがネットワーク環境とハードウェアに適用される方法を理解してください。

たとえば、タスク マネージャー を開き、サーバー上の論理プロセッサを確認し、受信トラフィックに対して過小使用されているように見える場合は、RSS キューの数を既定の 2 からネットワーク アダプターがサポートする最大数に増やしてみてください。 ネットワーク アダプターによっては、ドライバーの一部として RSS キュー数を変更するオプションがあります。

ネットワーク アダプター リソースの増加

受信バッファーや送信バッファーなどのリソースを手動で構成できるネットワーク アダプターの場合は、割り当てられたリソースを増やす必要があります。

ネットワーク アダプターによっては、受信バッファーを低く設定して、ホストから割り当てられるメモリを節約している場合があります。 値を低くすると、パケットが損失し、パフォーマンスが低下します。 そのため、受信量が多いシナリオの場合、受信バッファー値を最大値まで増やすことをお勧めします。

注意

ネットワーク アダプターが手動のリソース構成を公開しない場合は、リソースを動的に構成するか、リソースを変更できない固定値に設定します。

割り込みモデレーションの有効化

割り込みモデレーションを制御するために、一部のネットワーク アダプターでは、さまざまな割り込みモデレーション レベル、異なるバッファー合体パラメーター (場合によっては送信バッファーと受信バッファー用に個別に)、または両方が公開されます。

CPU バインド ワークロードの割り込みモデレーションを検討する必要があります。 割り込みモデレーションを使用する場合は、割り込みの増加と待機時間の短縮により、ホストの CPU の節約と待機時間の間のトレードオフを考慮してください。 ネットワーク アダプターが割り込みモデレーションを実行しないが、バッファー合体を公開している場合は、合体バッファーの数を増やして送信または受信あたりのバッファー数を増やしてパフォーマンスを向上させることができます。

待機時間の短いパケット処理のパフォーマンス チューニング

多くのネットワーク アダプターには、オペレーティング システムが原因の待機時間を最適化するオプションがあります。 待機時間は、ネットワーク ドライバーが着信パケットを処理してから、ネットワーク ドライバーがパケットを返送するまでの経過時間です。 通常、この時間はマイクロ秒単位で測定されます。 比較のために、通常、長距離間のパケット送信の送信時間は、ミリ秒単位 (1 桁大きい単位) で測定されます。 この調整によって、パケットの送信にかかる時間は短縮されません。

次に、精度がマイクロ秒のネットワークのパフォーマンス チューニングをいくつか提案します。

  • コンピューターの BIOS を、C 状態を無効にして High Performance (高パフォーマンス) に設定します。 この設定はシステムと BIOS によって変わる点に注意してください。一部のシステムは、オペレーティング システムが電源管理を制御している場合に、パフォーマンスが高くなります。 電源管理設定の確認と調整は、設定powercfg コマンドを使用して行います。 詳細については、「Powercfg のオプション」 をCommand-Lineしてください

  • オペレーティング システムの電源管理プロファイルを 高パフォーマンス システムに設定します。

    注意

    システム BIOS が電源管理のオペレーティング システム制御を無効に設定されている場合、この設定は正しく機能しません。

  • 静的オフロードを有効にする。 たとえば、UDP チェックサム、TCP チェックサム、および LSO (Large Offload) の送信設定を有効にします。

  • トラフィックがマルチストリームである場合 (高ボリューム マルチキャスト トラフィックを受信する場合など)、RSS を有効にしてください。

  • 待機時間をできるだけ短くする必要があるネットワーク カード ドライバーの場合、Interrupt Moderation (割り込み節度) を無効にします。 この構成では、より多くの CPU 時間を使用できます。これはトレードオフを表します。

  • パケットを処理するプログラム (ユーザー スレッド) に使用されているコアと CPU キャッシュを共有しているコア プロセッサで、ネットワーク アダプターの割り込みと DPC を処理します。 CPU アフィニティの調整を使用してプロセスを特定の論理プロセッサに誘導し、RSS の構成と組み合わせて、この処理を実行することができます。 割り込み、DPC、ユーザー モード スレッドに同じコアを使用すると、コアの使用に関する ISR、DPC、およびスレッドが競合することで負荷が増えるため、パフォーマンスが低下します。

システム管理の割り込み

多くのハードウェア システムでは、エラー修正コード (ECC) メモリ エラーの報告、従来の USB 互換性の維持、ファンの制御、BIOS 制御電源設定の管理など、さまざまなメンテナンス機能にシステム管理割り込み (SMI) が使用されています。

SMI はシステム上で最も優先度の高い割り込みであり、CPU を管理モードにします。 このモードでは、SMI が割り込みサービス ルーチン (通常は BIOS に含まれる) を実行している間、他のすべてのアクティビティが中断されます。

残念ながら、この動作により、待機時間が 100 マイクロ秒以上急増する可能性があります。

待機時間を最小限にする必要がある場合は、SMI を可能な限り低く抑えることができる BIOS バージョンをハードウェア プロバイダーに問い合わせることをお勧めします。 これらの BIOS バージョンは、多くの場合、"低待機時間 BIOS" または "SMI Free BIOS" と呼ばれます。ハードウェア プラットフォームでは、重要な機能 (冷却ファンなど) を制御するために使用されるため、SMI アクティビティを完全に排除できない場合があります。

注意

論理プロセッサが特別なメンテナンス モードで実行され、オペレーティング システムの介入を妨げるため、オペレーティング システムは SMIS を制御できません。

パフォーマンス チューニング TCP

次の項目を使用して、TCP のパフォーマンスを調整できます。

TCP 受信ウィンドウの自動設定

Windows Vista、Windows Server 2008、および Windows の以降のバージョンでは、Windows ネットワーク スタックは TCP 受信ウィンドウ自動調整レベルという名前の機能を使用して、TCP 受信ウィンドウ のサイズをネゴシエートします。 この機能では、TCP ハンドシェイク中のすべての TCP 通信について、定義された受信ウィンドウ サイズをネゴシエートできます。

Windows の以前のバージョンでは、Windows ネットワーク スタックで固定サイズの受信ウィンドウ (65,535 バイト) が使用され、接続の全体的なスループットが制限されました。 TCP 接続の合計達成可能スループットにより、ネットワークの使用シナリオが制限される可能性があります。 TCP 受信ウィンドウの自動設定を使用すると、これらのシナリオでネットワークを完全に使用できます。

特定のサイズの TCP 受信ウィンドウでは、次の式を使用して、1 つの接続の合計スループットを計算できます。

達成可能なスループットの合計 (バイト単位)TCP 受信ウィンドウのサイズ (バイト単位) * (1 / 接続待機時間 (秒))

たとえば、待機時間が 10 ミリ秒の接続の場合、達成可能なスループットの合計は 51 Mbps に制限されます。 この値は、大規模な企業ネットワーク インフラストラクチャに対して妥当です。 ただし、自動調整を使用して受信ウィンドウを調整することで、接続は 1 Gbps 接続の完全な行レートを実現できます。

一部のアプリケーションでは、TCP 受信ウィンドウのサイズを定義します。 アプリケーションで受信ウィンドウのサイズが定義されていない場合、リンク速度によって次のようにサイズが決定されます。

  • 1 メガバイト/秒 (Mbps) 未満: 8 キロバイト (KB)
  • 1 Mbps から 100 Mbps: 17 KB
  • 100 Mbps から 10 ギガビット/秒 (Gbps): 64 KB
  • 10 Gbps 以上: 128 KB

たとえば、1 Gbps ネットワーク アダプターがインストールされているコンピューターでは、ウィンドウ サイズは 64 KB である必要があります。

また、この機能では、ネットワークのパフォーマンスを向上させるために、他の機能もすべて使用できます。 これらの機能には、 RFC 1323で定義されている残りの TCP オプションが含まれます。 これらの機能を使用することにより、Windows ベースのコンピューターは、構成に応じて、サイズが小さく、定義された値でスケーリングされる TCP 受信ウィンドウのサイズをネゴシエートできます。 この動作により、ネットワークデバイスのサイズがより簡単に処理できるようになります。

注意

RFC 1323で定義されているように、ネットワークデバイスがTCP ウィンドウスケールオプションに準拠していないという問題が発生する可能性があります。そのため、はスケールファクターをサポートしていません。 このような場合は、この KB 934430 を参照してください。ファイアウォールデバイスの背後で Windows Vista を使用しようとすると、ネットワーク接続が失敗します。または、ネットワークデバイスベンダーのサポートチームに問い合わせてください。

TCP 受信ウィンドウの自動チューニングレベルを確認して構成する

netsh コマンドまたは Windows PowerShell コマンドレットのいずれかを使用して、TCP 受信ウィンドウの自動調整レベルを確認または変更できます。

注意

Windows の以前 Windows 10 または Windows サーバー2019のバージョンとは異なり、レジストリを使用して TCP 受信ウィンドウサイズを構成することはできなくなりました。 非推奨の設定の詳細については、「 非推奨の TCP パラメーター」を参照してください。

注意

使用可能な自動チューニングレベルの詳細については、「自動 チューニングレベル」を参照してください。

Netsh を使用して自動チューニングレベルを確認または変更するには

現在の設定を確認するには、コマンドプロンプトウィンドウを開き、次のコマンドを実行します。

netsh interface tcp show global

このコマンドの出力は次のようになります。

Querying active state...

TCP Global Parameters
-----
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
Fast Open : enabled
Fast Open Fallback : enabled
Pacing Profile : off

この設定を変更するには、コマンドプロンプトで次のコマンドを実行します。

netsh interface tcp set global autotuninglevel=<Value>

注意

上記のコマンドでは、 <<は > 自動チューニングレベルの新しい値を表します。

このコマンドの詳細については、「 インターフェイス伝送制御プロトコル用の Netsh コマンド」を参照してください。

Powershell を使用して自動チューニングレベルを確認または変更するには

現在の設定を確認するには、PowerShell ウィンドウを開き、次のコマンドレットを実行します。

Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal

このコマンドレットの出力は、次のようになります。

SettingName           AutoTuningLevelLocal
-----------          --------------------
Automatic
InternetCustom       Normal
DatacenterCustom     Normal
Compat               Normal
Datacenter           Normal
Internet             Normal

設定を変更するには、PowerShell コマンドプロンプトで次のコマンドレットを実行します。

Set-NetTCPSetting -AutoTuningLevelLocal <Value>

注意

上記のコマンドでは、 <<は > 自動チューニングレベルの新しい値を表します。

これらのコマンドレットの詳細については、次の記事を参照してください。

自動チューニングレベル

受信ウィンドウの自動チューニングは、5つのレベルのいずれかに設定できます。 既定のレベルは Normalです。 次の表では、これらのレベルについて説明します。

Level 16 進数値 コメント
[標準] (既定) 0x8 (スケールファクターは 8) ほとんどすべてのシナリオに対応できるように、TCP 受信ウィンドウを拡張するように設定します。
無効 使用できるスケールファクターがありません TCP 受信ウィンドウを既定値で設定します。
制限付き 0x4 (スケールファクター 4) TCP 受信ウィンドウを既定値を超えて拡張するように設定しますが、一部のシナリオではこのような増加を制限します。
高制限 0x2 (スケールファクター 2) TCP 受信ウィンドウを既定値を超えて拡張するように設定しますが、非常に控えめです。
実験用 0xE (スケールファクター 14) 極端なシナリオに対応できるように、TCP 受信ウィンドウを拡張するように設定します。

アプリケーションを使用してネットワークパケットをキャプチャする場合、アプリケーションは、ウィンドウの自動チューニングレベルの設定に応じて、次のようなデータを報告する必要があります。

  • 自動チューニングレベル: 標準 (既定の状態)

    Frame: Number = 492, Captured Frame Length = 66, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2667, Total IP Length = 52
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60975, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=4075590425, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
    SrcPort: 60975
    DstPort: Microsoft-DS(445)
    SequenceNumber: 4075590425 (0xF2EC9319)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 128 (0x80)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( Negotiating scale factor 0x8 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x8 Scale Factor.
    Checksum: 0x8182, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + WindowsScaleFactor: ShiftCount: 8 -----------------------------> Scale factor, defined by AutoTuningLevel
    + NoOption:
    + NoOption:
    + SACKPermitted:
    
  • 自動チューニングレベル: 無効

    Frame: Number = 353, Captured Frame Length = 62, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2576, Total IP Length = 48
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60956, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2315885330, Ack=0, Win=64240 ( ) = 64240
    SrcPort: 60956
    DstPort: Microsoft-DS(445)
    SequenceNumber: 2315885330 (0x8A099B12)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 112 (0x70)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( ) = 64240 ----------------------------------------> TCP Receive Window set as 64K as per NIC Link bitrate. Note there is no Scale Factor defined. In this case, Scale factor is not being sent as a TCP Option, so it will not be used by Windows.
    Checksum: 0x817E, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + NoOption:
    + SACKPermitted:
    
  • 自動チューニングレベル: 制限付き

    Frame: Number = 3, Captured Frame Length = 66, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2319, Total IP Length = 52
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60890, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1966088568, Ack=0, Win=64240 ( Negotiating scale factor 0x4 ) = 64240
    SrcPort: 60890
    DstPort: Microsoft-DS(445)
    SequenceNumber: 1966088568 (0x75302178)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 128 (0x80)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( Negotiating scale factor 0x4 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x4 Scale Factor.
    Checksum: 0x8182, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + WindowsScaleFactor: ShiftCount: 4 -------------------------------> Scale factor, defined by AutoTuningLevel.
    + NoOption:
    + NoOption:
    + SACKPermitted:
    
  • 自動チューニングレベル: 高い制限

    Frame: Number = 115, Captured Frame Length = 66, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2388, Total IP Length = 52
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60903, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1463725706, Ack=0, Win=64240 ( Negotiating scale factor 0x2 ) = 64240
    SrcPort: 60903
    DstPort: Microsoft-DS(445)
    SequenceNumber: 1463725706 (0x573EAE8A)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 128 (0x80)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( Negotiating scale factor 0x2 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x2 Scale Factor.
    Checksum: 0x8182, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + WindowsScaleFactor: ShiftCount: 2 ------------------------------> Scale factor, defined by AutoTuningLevel
    + NoOption:
    + NoOption:
    + SACKPermitted:
    
  • 自動チューニングレベル: 試験段階

    Frame: Number = 238, Captured Frame Length = 66, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2490, Total IP Length = 52
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60933, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2095111365, Ack=0, Win=64240 ( Negotiating scale factor 0xe ) = 64240
    SrcPort: 60933
    DstPort: Microsoft-DS(445)
    SequenceNumber: 2095111365 (0x7CE0DCC5)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 128 (0x80)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0xe Scale Factor.
    Checksum: 0x8182, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + WindowsScaleFactor: ShiftCount: 14 -----------------------------> Scale factor, defined by AutoTuningLevel
    + NoOption:
    + NoOption:
    + SACKPermitted:
    

非推奨の TCP パラメーター

Windows Server 2003 からの次のレジストリ設定はサポートされなくなり、以降のバージョンでは無視されます。

  • TcpWindowSize
  • NumTcbTablePartitions
  • MaxHashTableSize

これらの設定はすべて、次のレジストリサブキーにありました。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Windows フィルタリング プラットフォーム

WindowsVista および Windows Server 2008 では、Windows Filtering Platform (WFP) が導入されました。 WFP は、Microsoft 以外の独立系ソフトウェアベンダー (Isv) に Api を提供して、パケット処理フィルターを作成します。 たとえば、ファイアウォールとウイルス対策ソフトウェアが含まれています。

注意

正しく記述されていない WFP フィルターを使用すると、サーバーのネットワークパフォーマンスが大幅に低下する可能性があります。 詳細については、「Windows デベロッパーセンターでPacket-Processing ドライバーとアプリを WFP に移植する」を参照してください。

このガイドのすべてのトピックへのリンクについては、「 ネットワークサブシステムのパフォーマンスチューニング」を参照してください。