Schede di rete di ottimizzazione delle prestazioni
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.
Importante
Non usare le funzionalità di offload delle attività IPsec Task 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, 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.
Nota
Per alcuni adattatori di rete, è necessario abilitare le funzionalità di offload in modo indipendente per 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 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.
Importante
Evitare di usare entrambe gli adattatori di rete non RSS e gli adattatori 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 un adattatore di rete non compatibile con RSS accetta il traffico Web in un server con uno o più adattatori di rete che supportano RSS. In questa circostanza, è consigliabile utilizzare adattatori di rete che supportano RSS o disabilitare RSS nelle proprietà dell'adattatore di rete, nella scheda Proprietà avanzate.
Per determinare se un adattatore di rete è in grado di supportare RSS, è possibile visualizzare le informazioni RSS nelle proprietà dell'adattatore di rete, nella scheda Proprietà avanzate.
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.
Nota
Se un adattatore di rete non consente la configurazione manuale delle risorse, tale configurazione viene effettuata in modo dinamico oppure per le risorse viene impostato un valore fisso che non può essere modificato.
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).
Nota
Il sistema operativo non può esercitare alcun controllo sugli SMI, perché il processore logico viene eseguito in una speciale modalità di manutenzione che impedisce l'intervento del sistema operativo.
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.
Nota
È possibile che si verifichi un problema in cui il dispositivo di rete non è conforme all'opzione di scalabilità della finestra 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 maggiori informazioni sulle impostazioni deprecate, consultare la sezione Parametri TCP deprecati.
Nota
Per informazioni dettagliate sui livelli di ottimizzazione automatica disponibili, consultare la sezione Livelli di ottimizzazione automatica.
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>
Nota
Nel comando precedente, <Value> rappresenta il nuovo valore per il livello di ottimizzazione automatica.
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>
Nota
Nel comando precedente, <Value> rappresenta il nuovo valore per il livello di ottimizzazione automatica.
Per maggiori 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 è Normale. Nella seguente tabella, vengono descritti i livelli.
| Livello | Valore esadecimale | Commenti |
|---|---|---|
| Normale (valore predefinito) | 0x8 (fattore di scala pari a 8) | Impostare la finestra di ricezione TCP per aumentare in modo da supportare quasi tutti gli scenari. |
| Disabilitata | 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 pari a 2) | Impostare la finestra di ricezione TCP per aumentare oltre il valore predefinito, ma farlo in modo molto conservativo. |
| Sperimentale | 0xE (fattore di scala pari a 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: 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.
Nota
Un filtro Piattaforma filtro Windows non scritto in modo corretto può ridurre in misura significativa le prestazioni di rete di un server. Per maggiori informazioni, consultare la sezione 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, consultare la sezione Ottimizzazione delle prestazioni del sottosistema di rete.