Ottimizzazione delle prestazioni della scheda di rete in Windows Server

Questo articolo descrive come ottimizzare le prestazioni delle schede di rete negli ambienti Windows Server. L'ottimizzazione delle prestazioni della scheda di rete può migliorare significativamente la velocità effettiva, ridurre la latenza e ottimizzare l'utilizzo delle risorse per i carichi di lavoro del server.

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

Le impostazioni di ottimizzazione ottimali dipendono dalla configurazione hardware, dai requisiti del carico di lavoro e dagli obiettivi di prestazioni specifici. Prima di implementare le modifiche, valutare le prestazioni di rete correnti e identificare le aree per il miglioramento. Alcune funzionalità e impostazioni possono variare tra le versioni.

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

Offload features

Le funzionalità di offload di rete trasferisce le attività di elaborazione dalla CPU all'hardware della scheda di rete, riducendo il sovraccarico del sistema e migliorando le prestazioni complessive della rete. Le funzionalità di offload comuni includono l'offload checksum TCP, l'offload di invio di grandi dimensioni (LSO) e il ridimensionamento lato ricezione (RSS).

L'abilitazione delle funzionalità di offload della scheda di rete è in genere utile. 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, 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, è necessario abilitare le funzionalità di offload di segmentazione.

Per alcuni adattatori di rete, è necessario abilitare le funzionalità di offload in modo indipendente per percorsi di invio e ricezione.

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 predefinito è NUMAStatic. 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.

For example, open Task Manager and review the logical processors on your server. Se 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. La scheda di rete potrebbe avere opzioni per modificare il numero di code RSS come parte del driver.

Risorse della scheda 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.

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

Interrupt moderation

Per controllare la moderazione degli interrupt, alcuni adattatori di rete espongono diversi livelli di moderazione degli interrupt, diversi parametri di aggregazione dei buffer (a volte separatamente per i buffer di invio e di ricezione), o 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 la scheda di rete non esegue la moderazione degli interrupt, ma espone il raggruppamento dei buffer, è possibile migliorare le prestazioni aumentando il numero di buffer raggruppati per consentire più buffer per invio o ricezione.

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 regolazione non riduce il tempo di transito di un pacchetto.

L'elenco seguente fornisce alcuni suggerimenti per l'ottimizzazione delle prestazioni per le reti sensibili ai microsecondi:

• If your BIOS supports it, set the computer BIOS to High Performance, with C-states disabled. Alcuni sistemi offrono prestazioni più elevate se il sistema operativo controlla il risparmio energia. È possibile controllare e regolare le impostazioni di risparmio energia dalle impostazioni di risparmio energia o usando il powercfg comando . 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. Questa impostazione non funziona correttamente se il BIOS di sistema è impostato per disabilitare il controllo del sistema operativo del risparmio energia.

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

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

• Disable the Interrupt Moderation setting for network card drivers that require the lowest possible latency. È importante ricordare che questa configurazione può comportare un maggiore utilizzo di tempo di CPU e rappresenta una soluzione di compromesso.

• Gestione delle interruzioni degli adattatori di rete e dei DPC su un core processore che condivide la cache CPU con il core utilizzato dal programma (thread utente) che gestisce il pacchetto. L'ottimizzazione dell'affinità cpu può essere usata per indirizzare un processo a determinati processori logici con la configurazione RSS. Utilizzando lo stesso core per l'interrupt, il DPC e il thread in modalità utente, le prestazioni peggiorano con l'aumentare del carico, perché l'ISR, il DPC e il thread competono per l'uso del core.

Interruzioni di gestione del sistema

Molti sistemi hardware usano gli interrupt di gestione del sistema (SMI) per varie funzioni di manutenzione, ad esempio la segnalazione di errori di memoria del codice di correzione degli errori (ECC), il mantenimento della compatibilità USB legacy, il controllo della ventola e la gestione delle impostazioni di alimentazione del 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 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 i fan di raffreddamento.

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.

Regolazione automatica della finestra di ricezione TCP

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 e può migliorare le prestazioni delle connessioni TCP.

In precedenza lo stack di rete di Windows usava una finestra di ricezione a dimensione fissa di 65.535 byte che limitava la velocità effettiva complessiva potenziale 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 una dimensione specifica, è 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 da 1 Gbps 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 frequenza completa di 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:

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

Questa funzionalità usa anche tutte le altre funzionalità per migliorare le prestazioni di rete. These features include the rest of the TCP options that are defined in RFC 1323. I computer basati su Windows possono usare queste funzionalità per 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.

Autotuning levels

È possibile impostare la sincronizzazione automatica della finestra di ricezione TCP su uno dei cinque livelli. The default level is Normal. Nella seguente tabella, vengono descritti i livelli.

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

Livello di ottimizzazione automatica: Normale (stato predefinito)

This example shows the output of a packet capture tool when the TCP receive window autotuning level is set to Normal. Il fattore di scala è 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:

Livello di ottimizzazione automatica: Disabilitato

This example shows the output of a packet capture tool when the TCP receive window autotuning level is set to Disabled. Il fattore di scala non viene usato.

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

This example shows the output of a packet capture tool when the TCP receive window autotuning level is set to Restricted. Il fattore di scala è 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:

Livello di ottimizzazione automatica: altamente limitato

This example shows the output of a packet capture tool when the TCP receive window autotuning level is set to Highly Restricted. Il fattore di scala è 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:

Livello di ottimizzazione automatica: sperimentale

This example shows the output of a packet capture tool when the TCP receive window autotuning level is set to Experimental. Il fattore di scala è 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:

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

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

Piattaforma filtro Windows

Windows Filtering Platform (WFP), introdotto in Windows Server 2008, fornisce API ai fornitori di software indipendenti (ISV) non Microsoft per creare filtri di elaborazione pacchetti. WFP consente al software di terze parti di controllare, modificare o filtrare il traffico di rete a vari livelli dello stack di rete. Sebbene questa funzionalità sia essenziale per le applicazioni di sicurezza, può comportare un sovraccarico delle prestazioni se non implementato correttamente. Ne sono esempi i software per firewall e antivirus.

Un filtro WFP scritto male può ridurre significativamente 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.

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 di sistema: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters