Schede di rete di ottimizzazione delle prestazioni

  • Articolo

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 le schede di rete delle prestazioni per i computer che eseguono Windows Server 2016 e versioni successive. Se le schede 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 le schede di rete dipendono dalle variabili seguenti:

  • La scheda di rete e il relativo set di funzionalità
  • 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, la scheda di rete potrebbe non essere abbastanza potente per gestire le funzionalità di offload con velocità effettiva elevata.

Importante

Non usare le funzionalità di offload delle attività IPsec Offload o TCP Chimney Offload. Queste tecnologie sono deprecate in Windows Server 2016 e potrebbero influire negativamente sulle prestazioni del server e della rete. Inoltre, queste tecnologie potrebbero non essere supportate da Microsoft in futuro.

Si consideri, ad esempio, una scheda 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.

Nota

Alcune schede di rete richiedono di abilitare le funzionalità di offload in modo indipendente per i percorsi di invio e ricezione.

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 tutto il traffico Web passa attraverso le schede di rete con supporto RSS, il server può elaborare le richieste Web in ingresso da connessioni diverse contemporaneamente tra CPU diverse.

Importante

Evitare di usare entrambe le schede di rete non RSS e le schede di rete che supportano RSS nello stesso server. A causa della logica di distribuzione del carico in RSS e HTTP (Hypertext Transfer Protocol), le prestazioni potrebbero essere notevolmente ridotte se una scheda di rete non compatibile con RSS accetta il traffico Web in un server con una o più schede di rete che supportano RSS. In questa circostanza, è consigliabile utilizzare schede di rete che supportano RSS o disabilitare RSS nella scheda Proprietà avanzate della scheda di rete.

Per determinare se una scheda di rete è in grado di supportare RSS, è possibile visualizzare le informazioni RSS nella scheda Proprietà avanzate della scheda scheda di rete.

Profili RSS e code RSS

Il profilo predefinito RSS predefinito è 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 comprendere quando sono utili e come si applicano all'ambiente di rete e all'hardware.

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

Aumento delle risorse della scheda di rete

Per le schede di rete che consentono di configurare manualmente risorse come ricezione e invio di buffer, è consigliabile 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.

Nota

Se una scheda di rete non espone la configurazione manuale delle risorse, configura dinamicamente le risorse o le risorse vengono impostate su un valore fisso che non può essere modificato.

Abilitazione della moderazione degli interrupt

Per controllare la moderazione degli interrupt, alcune schede di rete espongono livelli di moderazione degli interrupt diversi, parametri di unione del buffer diversi (a volte separatamente per i buffer di invio e ricezione) o entrambi.

È consigliabile prendere in considerazione la moderazione degli interrupt per i carichi di lavoro associati alla CPU. Quando si usa la moderazione degli interrupt, prendere in considerazione il compromesso tra il risparmio della CPU host e la latenza rispetto al risparmio di CPU host a causa di più interrupt e meno latenza. Se la scheda di rete non esegue la moderazione degli interrupt, ma espone l'unione del buffer, è possibile migliorare le prestazioni aumentando il numero di buffer uniti per consentire più 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 altre informazioni, vedere Opzioni della riga di comando di Powercfg.

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

    Nota

    Questa impostazione non funziona correttamente se il BIOS di sistema è stato impostato per disabilitare il controllo del sistema operativo del risparmio energia.

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

  • Se il traffico è multi-stream, ad esempio quando si riceve traffico multicast ad alto volume, abilitare RSS.

  • Disabilitare l'impostazione Di moderazione interrupt per i driver delle schede di rete che richiedono la latenza più bassa possibile. Tenere presente che questa configurazione può usare più tempo cpu e rappresenta un 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 errori di memoria 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ò comportare 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 vengono spesso definite "BIOS a bassa latenza" o "BIOS libero SMI". In alcuni casi, non è possibile che una piattaforma hardware elimini completamente l'attività SMI perché viene usata per controllare le funzioni essenziali (ad esempio, ventole di raffreddamento).

Nota

Il sistema operativo non può controllare le PMI perché il processore logico è in esecuzione in una modalità di manutenzione speciale, che impedisce l'intervento del sistema operativo.

Ottimizzazione delle prestazioni TCP

Per ottimizzare le prestazioni TCP, è possibile usare gli elementi seguenti.

Ottimizzazione automatica della finestra di ricezione 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.

Nota

È possibile che si verifichi un problema in cui il dispositivo di rete non è conforme all'opzione di scalabilità delle finestre TCP, come definito in RFC 1323 e, pertanto, non supporta il fattore di scala. In questi casi, fare riferimento a questo KB 934430, la connettività di rete non riesce quando si tenta di usare Windows Vista dietro un dispositivo firewall o contattare il team di supporto per il fornitore del dispositivo 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.

Nota

A differenza delle versioni di Windows che pre-data Windows 10 o Windows Server 2019, non è più possibile usare il Registro di sistema per configurare le dimensioni della finestra di ricezione TCP. Per altre informazioni sulle impostazioni deprecate, vedere Parametri TCP deprecati.

Nota

Per informazioni dettagliate sui livelli di ottimizzazione automatica disponibili, vedere Livelli di ottimizzazione automatica.

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

Per esaminare 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 dovrebbe essere 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>

Nota

Nel comando precedente Value <> rappresenta il nuovo valore per il livello di ottimizzazione automatica.

Per altre informazioni su questo comando, vedere 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 dovrebbe essere simile al seguente.

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

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

Set-NetTCPSetting -AutoTuningLevelLocal <Value>

Nota

Nel comando precedente Value <> rappresenta il nuovo valore per il livello di ottimizzazione automatica.

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

Livelli di ottimizzazione automatica

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

Livello Valore esadecimale Commenti
Normale (impostazione predefinita) 0x8 (fattore di scala pari a 8) Impostare la finestra di ricezione TCP per aumentare in modo da supportare quasi tutti gli scenari.
Disabled Nessun fattore di scala disponibile Impostare la finestra di ricezione TCP con il valore predefinito.
Limitata 0x4 (fattore di scala pari a 4) Impostare la finestra di ricezione TCP per aumentare oltre il valore predefinito, ma limitare tale crescita in alcuni scenari.
Con restrizioni estremamente limitate 0x2 (fattore di scala di 2) Impostare la finestra di ricezione TCP per aumentare oltre il valore predefinito, ma farlo in modo molto conservativo.
Sperimentale 0xE (fattore di scala di 14) Impostare la finestra di ricezione TCP in modo che si adatti a scenari estremi.

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: con restrizioni

    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 impostazioni del Registro di sistema seguenti 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 di sistema:

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.

Nota

Un filtro WFP scritto in modo non adeguato può ridurre significativamente le prestazioni di rete di un server. Per altre informazioni, vedere Conversione di driver e app per l'elaborazione di pacchetti in WFP in Windows Dev Center.

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