Schede di rete di ottimizzazione delle prestazioni

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versioni 21H2 e 20H2

Usare le informazioni contenute in questo argomento per ottimizzare gli adattatori di rete delle prestazioni per i computer che eseguono Windows Server 2016 e versioni successive. Se gli adattatori di rete offrono opzioni di ottimizzazione, è possibile usare queste opzioni per ottimizzare la velocità effettiva della rete e l'utilizzo delle risorse.

Le impostazioni di ottimizzazione corrette per gli adattatori di rete dipende dalle variabili seguenti:

• La scheda di rete e il relativo set di funzionalità
• Il tipo di carico di lavoro eseguito dal server
• Le risorse hardware e software del server
• Gli obiettivi in termini di prestazioni del server

Nelle sezioni seguenti vengono illustrate alcune delle opzioni di ottimizzazione disponibili.

Abilitazione delle funzionalità di offload

Di norma è utile attivare l'offload della scheda di rete. Tuttavia, l'adattatore di rete potrebbe non essere sufficientemente potente per gestire le funzionalità di offload con una velocità effettiva elevata.

Si consideri, ad esempio, un adattatore di rete con risorse hardware limitate. In tal caso, l'abilitazione delle funzionalità di offload di segmentazione potrebbe ridurre la velocità effettiva massima sostenibile dell'adattatore. Tuttavia, se la velocità effettiva ridotta è accettabile, è consigliabile procedere con un'abilitazione delle funzionalità di offload di segmentazione.

Abilitazione del ridimensionamento lato ricezione (RSS) per i server Web

Con RSS è possibile migliorare scalabilità e prestazioni Web se il server dispone di un numero di schede di rete inferiore al numero di processori logici. Quando l'intero traffico Web passa attraverso gli adattatori di rete che supportano RSS, il server può elaborare le richieste Web in arrivo da diverse connessioni simultaneamente tra diverse CPU.

Profili RSS e code RSS

Il profilo predefinito RSS è NUMAStatic, che differisce dall'impostazione predefinita rispetto alle versioni precedenti di Windows usate. Prima di iniziare a usare i profili RSS, esaminare i profili disponibili per capire quando sono vantaggiosi e come si applicano all'ambiente di rete e all'hardware.

Se, ad esempio, si apre Gestione attività, si esaminano i processori logici nel server e questi sembrano sottoutilizzati per la ricezione del traffico, è possibile aumentare il numero di code RSS dal numero predefinito di due al massimo supportato dall'adattatore di rete. Nella scheda di rete, le opzioni per modificare il numero di code RSS potrebbero essere parte del driver.

Aumento delle risorse dell'adattatore di rete

Negli adattatori di rete che consentono la configurazione manuale delle risorse, come buffer di ricezione e di invio, è necessario aumentare le risorse allocate.

Alcune schede di rete impostano i buffer di ricezione su un valore basso per risparmiare memoria allocata dall'host. In presenza di un valore basso, alcuni pacchetti vengono scartati e le prestazioni calano. Di conseguenza, in caso di carichi di lavoro con attività di ricezione intensiva, è consigliabile portare al massimo il valore del buffer di ricezione.

Abilitazione della regolazione di interrupt

Per controllare la regolazione di interrupt, alcuni adattatori di rete espongono diversi livelli di regolazione di interrupt o parametri di aggregazione dei buffer (a volte separatamente per buffer di invio e di ricezione) entrambi.

È consigliabile prendere in considerazione la moderazione degli interrupt per i carichi di lavoro associati alla CPU. Quando si utilizza la moderazione degli interrupt, considerare il compromesso tra il risparmio e la latenza della CPU host rispetto all'aumento del risparmio della CPU dell'host a causa di un maggior numero di interrupt e di una minore latenza. Se l'adattatore di rete non esegue la regolazione di interrupt, ma espone l'aggregazione dei buffer, è possibile migliorare le prestazioni aumentando il numero di buffer aggregati per consentire un maggior numero di buffer per invio o ricezione.

Ottimizzazione delle prestazioni per l'elaborazione di pacchetti a bassa latenza

Molte schede di rete offrono opzioni di ottimizzazione della latenza indotta dal sistema operativo. La latenza è il tempo trascorso tra l'elaborazione di un pacchetto in arrivo da parte dell'unità di rete e la restituzione del pacchetto da parte dell'unità di rete. Questo intervallo di tempo è normalmente misurato in microsecondi. Per il confronto, il tempo di trasmissione per le trasmissioni di pacchetti su lunghe distanze viene in genere misurato in millisecondi (un ordine di grandezza maggiore). Questa ottimizzazione non accelererà il trasferimento dei pacchetti.

Seguono alcuni suggerimenti utili per l'ottimizzazione delle prestazioni di schede che rilevano i microsecondi.

• Impostare il BIOS del computer su Prestazioni elevate, con stati C disabilitati. Si noti tuttavia che questa operazione dipende dal sistema e dal BIOS e che alcuni sistemi forniranno prestazioni più elevate se il sistema operativo controlla il risparmio energia. È possibile controllare e regolare le impostazioni di risparmio energia da Impostazioni o usando il comando powercfg. Per maggiori informazioni, consultare la sezione Opzioni della riga di comando Powercfg.

• Impostare il profilo di risparmio energia del sistema operativo su Sistema a prestazioni elevate.

  Nota

  Questa impostazione non funzionerà correttamente se le impostazioni del BIOS del sistema prevedono la disattivazione del controllo del risparmio energia da parte del sistema operativo.

• Abilitare gli offload statici. Ad esempio, abilitare le impostazioni di checksum UDP, checksum e TCP ed LSO (Send Large Offload).

• Se il traffico è multiflusso, ad esempio, quando si riceve traffico multicast a volume elevato, abilitare RSS.

• Disabilitare l'impostazione Regolazione interrupt per i driver delle schede di rete che richiedono la latenza più bassa possibile. È importante ricordare che questa configurazione può comportare un maggiore utilizzo di tempo di CPU e rappresenta una soluzione di compromesso.

• Gestire interrupt di schede di rete e chiamate di procedura differita su un processore core che condivide cache CPU con il core usato dal programma (thread utente) che gestisce il pacchetto. A tale scopo, è possibile usare l'ottimizzazione dell'affinità CPU per indirizzare un processo verso determinati processori logici insieme alla configurazione di RSS. Usando lo stesso core per l'interrupt, chiamata di procedura differita e thread modalità utente thread le prestazioni peggiorano con l'aumentare del carico, perché IRS, chiamata di procedura differita e thread competono per l'uso del core.

Interrupt di gestione del sistema

Molti sistemi hardware usano gli interrupt di gestione del sistema (SMI) per un'ampia gamma di funzioni di manutenzione, ad esempio, la segnalazione di ECC (Error Correction Code), il mantenimento della compatibilità USB legacy, il controllo della ventola e la gestione delle impostazioni di alimentazione controllate dal BIOS.

SMI è l'interrupt con priorità più alta nel sistema e inserisce la CPU in una modalità di gestione. Questa modalità impedisce tutte le altre attività mentre SMI esegue una routine del servizio di interrupt, in genere contenuta nel BIOS.

Sfortunatamente, questo comportamento può portare a picchi di latenza di 100 microsecondi o più.

Se è necessario ridurre al minimo la latenza, è opportuno richiedere al provider hardware una versione BIOS che riduca gli SMI il più possibile. Queste versioni del BIOS sono spesso denominate "BIOS a bassa latenza" o "BIOS senza SMI". In alcuni casi, non è possibile per una piattaforma hardware eliminare del tutto l'attività SMI perché viene utilizzata per controllare funzioni essenziali (ad esempio, ventole di raffreddamento).

TCP ottimizzazione delle prestazioni

È possibile usare i seguenti elementi per ottimizzare TCP.

Ottimizzazione automatica della finestra TCP

In Windows Vista, Windows Server 2008 e versioni successive di Windows, lo stack di rete di Windows usa una funzionalità denominata Livello di ottimizzazione automatica della finestra di ricezione TCP per negoziare le dimensioni della finestra di ricezione TCP. Questa funzionalità può negoziare le dimensioni di una finestra di ricezione definita per ogni comunicazione TCP durante l'handshake TCP.

Nelle versioni precedenti di Windows, lo stack di rete di Windows usava una finestra di ricezione a dimensione fissa (65.535 byte) che limitava la velocità effettiva potenziale complessiva per le connessioni. La velocità effettiva totale ottenibile delle connessioni TCP potrebbe limitare gli scenari di utilizzo della rete. La regolazione automatica della finestra di ricezione TCP consente a questi scenari di usare completamente la rete.

Per una finestra di ricezione TCP con dimensioni specifiche, è possibile usare l'equazione seguente per calcolare la velocità effettiva totale di una singola connessione.

Velocità effettiva totale raggiungibile in byte = Dimensione della finestra di ricezione TCP in byte * (1/latenza di connessione in secondi)

Ad esempio, per una connessione con una latenza di 10 ms, la velocità effettiva totale ottenibile è di soli 51 Mbps. Questo valore è ragionevole per un'infrastruttura di rete aziendale di grandi dimensioni. Tuttavia, usando l'ottimizzazione automatica per regolare la finestra di ricezione, la connessione può raggiungere la velocità di riga completa di una connessione a 1 Gbps.

Alcune applicazioni definiscono le dimensioni della finestra di ricezione TCP. Se l'applicazione non definisce le dimensioni della finestra di ricezione, la velocità del collegamento determina le dimensioni come indicato di seguito:

• Minore di 1 megabit al secondo (Mbps): 8 kilobyte (KB)
• Da 1 Mbps a 100 Mbps: 17 KB
• Da 100 Mbps a 10 gigabit al secondo (Gbps): 64 KB
• 10 Gbps o superiore: 128 KB

Ad esempio, in un computer con una scheda di rete da 1 Gbps installata, le dimensioni della finestra devono essere di 64 KB.

Questa funzionalità usa anche tutte le altre funzionalità per migliorare le prestazioni di rete. Queste funzionalità includono le altre opzioni TCP definite in RFC 1323. Usando queste funzionalità, i computer basati su Windows possono negoziare le dimensioni delle finestre di ricezione TCP ridotte ma ridimensionate in base a un valore definito, a seconda della configurazione. Questo comportamento semplifica la gestione delle dimensioni per i dispositivi di rete.

Esaminare e configurare il livello di ottimizzazione automatica della finestra di ricezione TCP

È possibile usare i comandi netsh o i cmdlet di Windows PowerShell per esaminare o modificare il livello di ottimizzazione automatica della finestra di ricezione TCP.

Per usare netsh per rivedere o modificare il livello di ottimizzazione automatica

Per rivedere le impostazioni correnti, aprire una finestra del prompt dei comandi ed eseguire il comando seguente:

netsh interface tcp show global

L'output di questo comando sarà simile al seguente:

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

Per modificare l'impostazione, eseguire il comando seguente al prompt dei comandi:

netsh interface tcp set global autotuninglevel=<Value>

Per maggiori informazioni su questo comando, consultare la sezione Comandi Netsh per Interface Transmission Control Protocol.

Per usare Powershell, per esaminare o modificare il livello di ottimizzazione automatica

Per esaminare le impostazioni correnti, aprire una finestra di PowerShell ed eseguire il cmdlet seguente.

Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal

L'output di questo cmdlet sarà simile al seguente.

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

Per modificare l'impostazione, eseguire il seguente cmdlet al prompt dei comandi di PowerShell.

Set-NetTCPSetting -AutoTuningLevelLocal <Value>

Per maggiori informazioni su questi cmdlet, vedere gli articoli seguenti:

• Get-NetTCPSetting
• Set-NetTCPSetting

Livelli di ottimizzazione automatica

È possibile impostare l'ottimizzazione automatica della finestra di ricezione su uno dei cinque livelli. Il livello predefinito è Normale. Nella seguente tabella, vengono descritti i livelli.

Se si usa un'applicazione per acquisire pacchetti di rete, l'applicazione deve segnalare i dati simili ai seguenti per diverse impostazioni del livello di ottimizzazione automatica delle finestre.

• Livello di ottimizzazione automatica: Normale (stato predefinito)

  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:
  

• Livello di ottimizzazione automatica: Disabilitato

  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:
  

• Livello di ottimizzazione automatica: Limitato

  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:
  

• Livello di ottimizzazione automatica: Altamente limitato

  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:
  

• Livello di ottimizzazione automatica: Sperimentale

  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:
  

Parametri TCP deprecati

Le seguenti impostazioni del registro di Windows Server 2003 non sono più supportate e vengono ignorate nelle versioni successive.

• TcpWindowSize
• NumTcbTablePartitions
• MaxHashTableSize

Tutte queste impostazioni si trovavano nella seguente sottochiave del registro:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Piattaforma filtro Windows

Windows Vista e Windows Server 2008 hanno introdotto windows Filtering Platform (WFP). WFP fornisce API ai fornitori di software indipendenti (ISV) non Microsoft per creare filtri di elaborazione pacchetti. Ne sono esempi i software per firewall e antivirus.

Per i collegamenti a tutti gli argomenti di questa guida, consultare la sezione Ottimizzazione delle prestazioni del sottosistema di rete.