この記事では、Windows Server 環境でネットワーク アダプターのパフォーマンスを最適化する方法について説明します。 ネットワーク アダプターのパフォーマンス チューニングを行うと、スループットが大幅に向上し、待機時間が短縮され、サーバー ワークロードのリソース使用率が最大化されます。
ネットワーク アダプターの正しいチューニング設定は、次の変動要素に応じて決まります。
- ネットワーク アダプターとその機能セット
- サーバーが実行するワークロードの種類
- サーバーのハードウェアとソフトウェアのリソース
- サーバーのパフォーマンス目標
最適なチューニング設定は、特定のハードウェア構成、ワークロード要件、およびパフォーマンス目標によって異なります。 変更を実装する前に、現在のネットワーク パフォーマンスを評価し、改善する領域を特定します。 一部の機能と設定は、バージョンによって異なる場合があります。
以下のセクションでは、パフォーマンス チューニング オプションの一部について説明します。
オフロード機能
ネットワーク オフロード機能は、CPU からネットワーク アダプター ハードウェアに処理タスクを転送し、システムのオーバーヘッドを削減し、全体的なネットワーク パフォーマンスを向上させます。 一般的なオフロード機能には、TCP チェックサム オフロード、LSO (LSO)、Receive Side Scaling (RSS) があります。
ネットワーク アダプターのオフロード機能を有効化することは、一般的にメリットがあります。 ただし、ネットワーク アダプターの処理能力が足りず、高いスループットでオフロード機能を処理できない場合があります。 たとえば、ハードウェア リソースが限られているネットワーク アダプターを考えてみましょう。 その場合、セグメント化オフロード機能を有効にすると、アダプターの維持可能な最大スループットが低下する可能性があります。 ただし、スループットの削減が許容される場合は、セグメント化オフロード機能を有効にする必要があります。
一部のネットワーク アダプターでは、送信パスと受信パスで個別にオフロード機能を有効にする必要があります。
Important
オフロード機能 IPsec タスク オフロードまたは TCP のチムニー オフロードを使用しないでください。 これらのテクノロジは Windows Server 2016 では非推奨になっており、サーバーとネットワークのパフォーマンスに悪影響を及ぼす可能性があります。 さらに、Microsoft は将来、これらのテクノロジをサポートしない可能性があります。
Web サーバーの Receive Side Scaling (RSS)
サーバーの論理プロセッサよりもネットワーク アダプター数が少ない場合、RSS で Web のスケーラビリティとパフォーマンスを改善できます。 すべての Web トラフィックが RSS 対応ネットワーク アダプターを経由する場合、サーバーは異なる接続から受信した Web 要求を複数の CPU で同時に処理することができます。
Important
非 RSS ネットワーク アダプターと RSS 対応のネットワーク アダプターの両方を同じサーバー上で使用することは避けてください。 RSS とハイパーテキスト転送プロトコル (HTTP) の負荷分散ロジックのため、1 つまたは複数の RSS 対応ネットワーク アダプターを使用するサーバーの Web トラフィックを、RSS 対応ではないネットワーク アダプターで受け入れた場合、パフォーマンスが大幅に低下する可能性があります。 この状況では、RSS 対応のネットワーク アダプターを使用するか、ネットワーク アダプターのプロパティの [ 詳細なプロパティ ] タブで RSS を無効にする必要があります。
ネットワーク アダプターが RSS 対応かどうかを判断するには、[ネットワーク アダプターのプロパティの 詳細プロパティ ] タブで RSS 情報を表示できます。
RSS プロファイルと RSS キュー
既定の RSS 定義済みプロファイルは NUMAStatic です。 RSS プロファイルを使用する前に、使用できるプロファイルを確認すると、いつそれが役に立つか、また実際のネットワーク環境とハードウェアに適用する方法について理解できます。
たとえば、 タスク マネージャー を開き、サーバー上の論理プロセッサを確認します。 受信トラフィックの使用率が低いように見える場合は、RSS キューの数を既定の 2 からネットワーク アダプターがサポートする最大値に増やしてみてください。 ネットワーク アダプターによっては、ドライバーの一部として RSS キュー数を変更するオプションがあります。
ネットワーク アダプターのリソース
受信バッファーや送信バッファーなど、リソースを手動で構成できるネットワーク アダプターの場合、割り当てリソースを増やすことをお勧めします。
ネットワーク アダプターによっては、受信バッファーを低く設定して、ホストから割り当てられるメモリを節約している場合があります。 値を低くすると、パケットが損失し、パフォーマンスが低下します。 そのため、受信量が多いシナリオの場合、受信バッファー値を最大値まで増やすことをお勧めします。
ネットワーク アダプターに手動リソース構成機能がない場合、リソースが動的に構成されるか、リソースが変更できない固定値に設定されています。
割り込みモデレーション
一部のネットワーク アダプターには、割り込み節度を制御するために、複数の割り込み節度レベル、異なるバッファー結合パラメーター (場合によっては送信バッファーと受信バッファーで別に設定)、またはその両方の機能があります。
CPU にバインドされたワークロードでは、割り込み節度を考慮する必要があります。 割り込み節度を使用するときは、ホストの CPU の節約量と待機時間と、割り込みの増加と短い待機時間のためにホストの CPU の節約量が増えることとのトレードオフを考慮します。 ネットワーク アダプターが割り込み節度を実行せず、バッファーの結合機能がある場合、結合されるバッファー数を増やして 1 回の送信または受信あたりのバッファーを増やすことで、パフォーマンスを改善することができます。
低遅延パケット処理
多くのネットワーク アダプターには、オペレーティング システムが原因の待機時間を最適化するオプションがあります。 待機時間は、ネットワーク ドライバーが着信パケットを処理してから、ネットワーク ドライバーがパケットを返送するまでの経過時間です。 通常、この時間はマイクロ秒単位で測定されます。 比較のために、通常、長距離間のパケット送信の送信時間は、ミリ秒単位 (1 桁大きい単位) で測定されます。 このチューニングによって、パケットの送信にかかる時間は短縮されません。
次に、精度がマイクロ秒のネットワークのパフォーマンス チューニングをいくつか提案します。
BIOS でサポートされている場合は、コンピューターの BIOS を High Performance に設定し、
C-states無効にします。 オペレーティング システムが電源管理を制御する場合、一部のシステムではパフォーマンスが向上します。 電源管理設定は、電源設定から、またはpowercfgコマンドを使用して確認および調整できます。 詳しくは、「Powercfg のコマンドライン オプション」をご覧ください。オペレーティング システムの電源管理プロファイルを 高パフォーマンス システムに設定します。 システム BIOS が電源管理のオペレーティング システム制御を無効にするように設定されている場合、この設定は正しく機能しません。
静的オフロードを有効にします。 たとえば、UDP チェックサム、TCP チェックサム、Send Large Offload (LSO) の設定を有効にします。
大量のマルチキャスト トラフィックの受信時など、トラフィックがマルチストリームされる場合は、RSS を有効にします。
可能な限り短い待機時間を必要とするネットワーク カード ドライバーの 割り込みモデレーション 設定を無効にします。 ただし、この構成により CPU 時間が増える可能性があり、トレードオフの問題になります。
パケットを処理するプログラム (ユーザー スレッド) に使用されているコアと CPU キャッシュを共有しているコア プロセッサで、ネットワーク アダプターの割り込みと DPC を処理します。 CPU アフィニティ チューニングを使用すると、RSS 構成を使用してプロセスを特定の論理プロセッサに送信できます。 割り込み、DPC、ユーザー モード スレッドに同じコアを使用すると、コアの使用に関する ISR、DPC、およびスレッドが競合することで負荷が増えるため、パフォーマンスが低下します。
システム管理の割り込み
多くのハードウェア システムでは、エラー修正コード (ECC) メモリ エラーの報告、従来の USB 互換性の維持、ファンの制御、BIOS 制御の電源設定の管理など、さまざまなメンテナンス機能にシステム管理割り込み (SMI) が使用されています。
SMI は、システムで最も優先度が高い割り込みであり、CPU を管理モードにします。 SMI によって割り込みサービス ルーチン (通常は BIOS に含まれます) が実行されている間は、このモードが他すべてのアクティビティより優先されます。 残念ながら、この動作によって、待機時間が 100 マイクロ秒以上急上昇する可能性があります。
待機時間を最小限にする必要がある場合は、SMI を可能な限り低く抑えることができる BIOS バージョンをハードウェア プロバイダーに問い合わせることをお勧めします。 多くの場合、BIOS バージョンは、低遅延 BIOS や SMI フリー BIOS と呼ばれます。 場合によっては、SMI アクティビティが重要な機能 (冷却ファンなど) の制御に使用されているため、ハードウェア プラットフォームで SMI アクティビティを排除できない可能性があります。
論理プロセッサが特殊なメンテナンス モードで実行されており、オペレーティング システムが割り込みできないために、オペレーティング システムで SMI を制御できません。
TCP 受信ウィンドウの自動チューニング
Windows ネットワーク スタックでは、TCP 受信ウィンドウの自動チューニング レベル という名前の機能を使用して、TCP 受信ウィンドウ のサイズをネゴシエートします。 この機能は、TCP ハンドシェイク中に TCP 通信ごとに定義済みの受信ウィンドウ サイズをネゴシエートし、TCP 接続のパフォーマンスを向上させることができます。
以前は、Windows ネットワーク スタックでは、65,535 バイトの固定サイズの受信ウィンドウが使用され、接続の全体的な潜在的なスループットが制限されました。 TCP 接続の達成可能な合計スループットによって、ネットワークの使用シナリオが制限される可能性があります。 TCP 受信ウィンドウの自動チューニングを使用すると、これらのシナリオでネットワークを完全に使用できます。
特定のサイズの TCP 受信ウィンドウの場合、次の式を使用して、1 つの接続の合計スループットを計算できます:
達成可能な合計スループット (バイト) = TCP 受信ウィンドウのサイズ (バイト) * (1 / 接続の待機時間 (秒))
たとえば、待機時間が 10 ミリ秒の 1Gbps 接続の場合、達成可能なスループットの合計はわずか 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 受信ウィンドウ サイズをネゴシエートできます。 この動作により、ネットワーク デバイスのサイズをより簡単に処理できるようになります。
Note
RFC 1323 で定義されているように、ネットワーク デバイスが TCP ウィンドウ スケール オプションに準拠していないため、スケール ファクターがサポートされないという問題が発生する可能性があります。 このような場合は、ネットワーク デバイス ベンダーにお問い合わせください。
自動調整レベル
TCP 受信ウィンドウの自動チューニングは、5 つのレベルのいずれかに設定できます。 既定のレベルは 標準です。 次の表はレベルの説明です。
| Level | 16 進数の値 | Comments |
|---|---|---|
| 標準 (既定値) | 0x8 (スケール ファクター 8) | ほとんどすべてのシナリオに対応するまで拡大するように、TCP 受信ウィンドウを設定します。 |
| Disabled | 使用できるスケール ファクターはありません | TCP 受信ウィンドウを既定の値に設定します。 |
| Restricted | 0x4 (スケール ファクター 4) | 既定値より大きく拡大するように TCP 受信ウィンドウを設定しますが、一部のシナリオではそのような拡大は制限されます。 |
| 高度な制限 | 0x2 (スケール ファクター 2) | 既定値より大きく拡大するように TCP 受信ウィンドウを設定しますが、非常に控えめに行います。 |
| Experimental | 0xE (スケール ファクター 14) | 極端なシナリオに対応するまで拡大するように、TCP 受信ウィンドウを設定します。 |
アプリケーションを使用してネットワーク パケットをキャプチャする場合、アプリケーションは、ウィンドウの自動チューニング レベルの設定が異なる次の例のようなデータを報告する必要があります。
自動チューニング レベル: 標準 (既定の状態)
この例では、TCP 受信ウィンドウの自動チューニング レベルが Normal に設定されている場合のパケット キャプチャ ツールの出力を示します。 スケール ファクターは 8 です。
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:
自動チューニング レベル: 無効
この例では、TCP 受信ウィンドウの自動チューニング レベルが [無効] に設定されている場合のパケット キャプチャ ツールの出力を示します。 スケール ファクターは使用されません。
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:
自動チューニング レベル: 制限付き
この例では、TCP 受信ウィンドウの自動チューニング レベルが Restricted に設定されている場合のパケット キャプチャ ツールの出力を示します。 スケール ファクターは 4 です。
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:
自動チューニング レベル: 厳しい制限付き
この例では、TCP 受信ウィンドウの自動チューニング レベルが [高制限] に設定されている場合のパケット キャプチャ ツールの出力を示します。 スケール ファクターは 2 です。
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:
自動チューニング レベル: 実験用
この例では、TCP 受信ウィンドウの自動チューニング レベルが 試験段階に設定されている場合のパケット キャプチャ ツールの出力を示します。 スケール ファクターは 14 です。
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 PowerShell コマンドレットまたは netsh Windows コマンドを使用して、TCP 受信ウィンドウの自動チューニング レベルを確認または変更できます。
Note
Windows Server 2019 以降では、レジストリを使用して TCP 受信ウィンドウ サイズを構成することはできなくなります。 非推奨の設定について詳しくは、「非推奨の TCP パラメーター」をご覧ください。
Get-NetTCPSetting コマンドレットを使用して、自動チューニング レベルを確認または変更できます。 現在の設定を確認して変更するには:
管理者として PowerShell 開き、次のコマンドレットを実行します。
Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal出力は次の例のようになります。
SettingName AutoTuningLevelLocal ----------- -------------------- Automatic InternetCustom Normal DatacenterCustom Normal Compat Normal Datacenter Normal Internet Normal設定を変更するには、次のコマンドを実行します。
<value>を希望の自動チューニング レベルに設定してください。 詳細については、「 Set-NetTCPSetting」を参照してください。Set-NetTCPSetting -AutoTuningLevelLocal <value>
Windows フィルタリング プラットフォーム
Windows Server 2008 で導入された Windows フィルター プラットフォーム (WFP) は、Microsoft 以外の独立系ソフトウェア ベンダー (ISV) に API を提供して、パケット処理フィルターを作成します。 WFP を使用すると、サードパーティ製ソフトウェアは、ネットワーク スタックのさまざまなレイヤーでネットワーク トラフィックを検査、変更、またはフィルター処理できます。 この機能はセキュリティ アプリケーションに不可欠ですが、正しく実装されていない場合はパフォーマンスのオーバーヘッドが発生する可能性があります。 たとえば、ファイアウォールとウイルス対策ソフトウェアが含まれています。
不適切な WFP フィルターを作成すると、サーバーのネットワーク パフォーマンスが大幅に低下する可能性があります。 詳しくは、Windows デベロッパー センターの「パケット処理ドライバーとアプリの WFP への移植」をご覧ください。
非推奨の TCP パラメーター
Windows Server 2003 の次のレジストリ設定はサポートされなくなり、以降のバージョンでは無視されます。
- TcpWindowSize
- NumTcbTablePartitions
- MaxHashTableSize
これらの設定はすべて、次のレジストリ サブキーにありました: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters