ネットワーク アダプターのパフォーマンス チューニング
Windows Server 2016 以降のバージョンを実行しているコンピューターのパフォーマンス ネットワーク アダプターを調整するには、このトピックの情報を使用してください。 ネットワーク アダプターにチューニング オプションが用意されている場合は、これらのオプションを使用して、ネットワークのスループットとリソースの使用を最適化できます。
ネットワーク アダプターの正しいチューニング設定は、次の変動要素に応じて決まります。
- ネットワーク アダプターとその機能セット
- サーバーが実行するワークロードの種類
- サーバーのハードウェアとソフトウェアのリソース
- サーバーのパフォーマンス目標
以下のセクションでは、パフォーマンス チューニング オプションの一部について説明します。
オフロード機能を有効にする
ネットワーク アダプターのオフロード機能の調整には、一般的にメリットがあります。 ただし、ネットワーク アダプターの処理能力が足りず、高いスループットでオフロード機能を処理できない場合があります。
重要
オフロード機能の IPsec タスク オフロードまたは TCP Chimney オフロードは使用しないでください。 これらのテクノロジは Windows Server 2016 では非推奨になっており、サーバーとネットワークのパフォーマンスに悪影響を及ぼす可能性があります。 さらに、これらのテクノロジは Microsoft によって今後サポートされない可能性があります。
たとえば、ネットワーク アダプターのハードウェア リソースが限られているとします。 その場合、セグメント化オフロード機能を有効にすると、アダプターの維持可能な最大スループットが低下する可能性があります。 ただし、スループットの低下を許容できる場合は、セグメント化オフロード機能を有効にすることをお勧めします。
Note
一部のネットワーク アダプターでは、送信パスと受信パスで個別にオフロード機能を有効にする必要があります。
Web サーバーの Receive Side Scaling (RSS) を有効にする
サーバーの論理プロセッサよりもネットワーク アダプター数が少ない場合、RSS で Web のスケーラビリティとパフォーマンスを改善できます。 すべての Web トラフィックが RSS 対応ネットワーク アダプターを経由する場合、サーバーは異なる接続から受信した Web 要求を複数の CPU で同時に処理することができます。
重要
非 RSS ネットワーク アダプターと RSS 対応のネットワーク アダプターの両方を同じサーバー上で使用することは避けてください。 RSS とハイパーテキスト転送プロトコル (HTTP) の負荷分散ロジックのため、1 つまたは複数の RSS 対応ネットワーク アダプターを使用するサーバーの Web トラフィックを、RSS 対応ではないネットワーク アダプターで受け入れた場合、パフォーマンスが大幅に低下する可能性があります。 このような場合、RSS 対応ネットワーク アダプターを使用するか、ネットワーク アダプターのプロパティの [詳細プロパティ] タブで RSS を無効にすることをお勧めします。
ネットワーク アダプターが RSS 対応かどうかを判断するには、ネットワーク アダプターのプロパティの [詳細プロパティ] タブの RSS 情報を確認します。
RSS プロファイルと RSS キュー
RSS で定義されている既定のプロファイルは NUMAStatic であり、これは以前のバージョンの Windows で使用されていた既定値とは異なります。 RSS プロファイルを使い始める前に、使用できるプロファイルを確認し、それが役に立つ状況と、実際のネットワーク環境とハードウェアに適用する方法を理解してください。
たとえば、タスク マネージャーを開き、サーバーの論理プロセッサを確認し、受信トラフィックの使用率が低いと考えられる場合、RSS のキュー数を既定の 2 から、お使いのネットワーク アダプターでサポートされている最大値まで増やしてみることができます。 ネットワーク アダプターによっては、ドライバーの一部として RSS キュー数を変更するオプションがあります。
ネットワーク アダプターのリソースを増やす
受信バッファーや送信バッファーなど、リソースを手動で構成できるネットワーク アダプターの場合、割り当てリソースを増やすことをお勧めします。
ネットワーク アダプターによっては、受信バッファーを低く設定して、ホストから割り当てられるメモリを節約している場合があります。 値を低くすると、パケットが損失し、パフォーマンスが低下します。 そのため、受信量が多いシナリオの場合、受信バッファー値を最大値まで増やすことをお勧めします。
Note
ネットワーク アダプターに手動リソース構成機能がない場合、リソースが動的に構成されるか、リソースが変更できない固定値に設定されています。
割り込み節度を有効にする
一部のネットワーク アダプターには、割り込み節度を制御するために、複数の割り込み節度レベル、異なるバッファー結合パラメーター (場合によっては送信バッファーと受信バッファーで別に設定)、またはその両方の機能があります。
CPU にバインドされたワークロードでは、割り込み節度を考慮する必要があります。 割り込み節度を使用するときは、ホストの CPU の節約量と待機時間と、割り込みの増加と短い待機時間のためにホストの CPU の節約量が増えることとのトレードオフを考慮します。 ネットワーク アダプターが割り込み節度を実行せず、バッファーの結合機能がある場合、結合されるバッファー数を増やすことで、1 回の送信または受信あたりのバッファーが増え、パフォーマンスを向上させることができます。
低待機時間パケット処理のためのパフォーマンス チューニング
多くのネットワーク アダプターには、オペレーティング システムが原因の待機時間を最適化するオプションがあります。 待機時間は、ネットワーク ドライバーが着信パケットを処理してから、ネットワーク ドライバーがパケットを返送するまでの経過時間です。 通常、この時間はマイクロ秒単位で測定されます。 比較のために、通常、長距離間のパケット送信の送信時間は、ミリ秒単位 (1 桁大きい単位) で測定されます。 この調整によって、パケットの送信にかかる時間は短縮されません。
次に、精度がマイクロ秒のネットワークのパフォーマンス チューニングをいくつか提案します。
コンピューターの BIOS を、C 状態を無効にして High Performance (高パフォーマンス) に設定します。 この設定はシステムと BIOS によって変わる点に注意してください。一部のシステムは、オペレーティング システムが電源管理を制御している場合に、パフォーマンスが高くなります。 [設定] または powercfg コマンドを使用して、電源管理設定を確認し、調整することができます。 詳しくは、「Powercfg のコマンドライン オプション」をご覧ください。
オペレーティング システムの電源管理プロファイルを 高パフォーマンス システムに設定します。
Note
システムの BIOS で、オペレーティング システムの電源管理の制御が無効にされている場合、この設定は正しく機能しません。
静的オフロードを有効にします。 たとえば、UDP チェックサム、TCP チェックサム、Send Large Offload (LSO) の設定を有効にします。
大量のマルチキャスト トラフィックの受信時など、トラフィックがマルチストリームされる場合は、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 フリー BIOS" と呼ばれます。場合によっては、SMI アクティビティが重要な機能 (冷却ファンなど) の制御に使用されているため、ハードウェア プラットフォームで SMI アクティビティを排除できない可能性があります。
Note
論理プロセッサが特殊なメンテナンス モードで実行されており、オペレーティング システムが割り込みできないために、オペレーティング システムで SMI を制御できません。
TCP のパフォーマンス チューニング
次のものを使用して、TCP のパフォーマンスをチューニングできます。
TCP 受信ウィンドウの自動チューニング
Windows Vista、Windows Server 2008、およびそれ以降のバージョンの Windows では、Windows ネットワーク スタックにより、"TCP 受信ウィンドウの自動チューニング レベル" という機能を使用して、TCP 受信ウィンドウのサイズがネゴシエートされます。 この機能は、TCP ハンドシェイクの間にすべての TCP 通信について、定義されている受信ウィンドウ サイズをネゴシエートできます。
以前のバージョンの Windows では、接続全体で可能なスループットを制限する固定サイズの受信ウィンドウ (65,535 バイト) が Windows ネットワーク スタックで使用されていました。 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 受信ウィンドウ サイズをネゴシエートできます。 この動作により、ネットワーク デバイスのサイズをより簡単に処理できるようになります。
Note
ネットワーク デバイスが RFC 1323 で定義されている TCP ウィンドウ スケール オプションに準拠していないため、スケール ファクターがサポートされないという問題が発生する可能性があります。 そのような場合は、KB 934430 「ファイアウォール デバイスの背後で Windows Vista を使用しようとしてもネットワーク接続が失敗する」を参照するか、ネットワーク デバイス ベンダーのサポートチームに問い合わせてください。
TCP 受信ウィンドウの自動チューニング レベルを確認して構成する
netsh コマンドまたは Windows PowerShell コマンドレットを使用して、TCP 受信ウィンドウの自動チューニング レベルを確認または変更できます。
Note
Windows 10 または Windows Server 2019 より前のバージョンの Windows とは異なり、レジストリを使って TCP 受信ウィンドウ サイズを構成することはできなくなりました。 非推奨の設定について詳しくは、「非推奨の TCP パラメーター」をご覧ください。
Note
使用可能な自動チューニング レベルについて詳しくは、「自動チューニングのレベル」をご覧ください。
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>
Note
上のコマンドで、<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>
Note
上のコマンドで、<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 フィルタリング プラットフォーム
Windows Vista および Windows Server 2008 では、Windows フィルタリング プラットフォーム (WFP) が導入されました。 WFP では、パケット処理フィルターを作成するための API が、Microsoft 以外の独立系ソフトウェア ベンダー (ISV) に提供されます。 たとえば、ファイアウォールとウイルス対策ソフトウェアが含まれています。
Note
不適切な WFP フィルターを作成すると、サーバーのネットワーク パフォーマンスが大幅に低下する可能性があります。 詳しくは、Windows デベロッパー センターの「パケット処理ドライバーとアプリの WFP への移植」をご覧ください。
このガイドのすべてのトピックへのリンクについては、「ネットワーク サブシステムのパフォーマンス チューニング」を参照してください。