Prestaties van netwerkadapters afstemmen in Windows Server

In dit artikel wordt beschreven hoe u de prestaties van de netwerkadapter in Windows Server-omgevingen optimaliseert. Afstemming van netwerkadapterprestaties kan de doorvoer aanzienlijk verbeteren, de latentie verminderen en het gebruik van bronnen voor uw serverwerkloads maximaliseren.

De juiste afstemmingsinstellingen voor uw netwerkadapters zijn afhankelijk van de volgende variabelen:

• De netwerkadapter en de bijbehorende functieset
• Het type workload dat door de server wordt uitgevoerd
• De hardware- en softwarebronnen van de server
• Uw prestatiedoelen voor de server

De optimale afstemmingsinstellingen zijn afhankelijk van uw specifieke hardwareconfiguratie, workloadvereisten en prestatiedoelstellingen. Voordat u wijzigingen implementeert, evalueert u de huidige netwerkprestaties en identificeert u gebieden voor verbetering. Sommige functies en instellingen kunnen per versie verschillen.

In de volgende secties worden enkele van uw opties voor het afstemmen van prestaties beschreven.

Offloadfuncties

Netwerk offloadfuncties dragen verwerkingstaken over van de CPU naar de netwerkadapterhardware, waardoor de systeemoverhead wordt verminderd en de algehele netwerkprestaties worden verbeterd. Algemene offloadfuncties zijn onder andere TCP checksum offload, Large Send Offload (LSO) en Receive Side Scaling (RSS).

Het inschakelen van offloadfuncties voor netwerkadapters is meestal nuttig. De netwerkadapter is mogelijk echter niet krachtig genoeg om de offloadmogelijkheden met een hoge doorvoersnelheid te verwerken. Denk bijvoorbeeld aan een netwerkadapter met beperkte hardwarebronnen. In dat geval kan het inschakelen van segmentatie-offloadfuncties de maximale duurzame doorvoer van de adapter verminderen. Als de verminderde doorvoer echter acceptabel is, moet u de segmentatie-offloadfuncties inschakelen.

Voor sommige netwerkadapters moet u offloadfuncties onafhankelijk inschakelen voor de paden voor verzenden en ontvangen.

Schalen aan de ontvangstzijde (RSS) voor webservers

RSS kan de schaalbaarheid en prestaties van het web verbeteren wanneer er minder netwerkadapters zijn dan logische processors op de server. Wanneer al het internetverkeer via de RSS-capabele netwerkadapters gaat, kan de server binnenkomende webaanvragen van verschillende verbindingen tegelijk verwerken over verschillende CPU's.

RSS-profielen en RSS-wachtrijen

Het standaard vooraf gedefinieerde RSS-profiel is NUMAStatic. Voordat u RSS-profielen gaat gebruiken, bekijkt u de beschikbare profielen om te begrijpen wanneer ze nuttig zijn en hoe ze van toepassing zijn op uw netwerkomgeving en hardware.

Open bijvoorbeeld Taakbeheer en controleer de logische processors op uw server. Als ze te weinig worden gebruikt voor het ontvangen van verkeer, kunt u proberen het aantal RSS-wachtrijen te verhogen van de standaardwaarde van twee tot het maximum dat uw netwerkadapter ondersteunt. Uw netwerkadapter kan opties hebben om het aantal RSS-wachtrijen als onderdeel van het stuurprogramma te wijzigen.

Netwerkadapterbronnen

Voor netwerkadapters waarmee u resources zoals ontvangst- en verzendbuffers handmatig kunt configureren, moet u de toegewezen resources verhogen.

Sommige netwerkadapters stellen hun ontvangstbuffers laag in om toegewezen geheugen van de host te besparen. De lage waarde resulteert in verwijderde pakketten en verminderde prestaties. Daarom raden we u aan voor ontvangstintensieve scenario's de waarde van de ontvangstbuffer te verhogen tot het maximum.

Als een netwerkadapter geen handmatige resourceconfiguratie beschikbaar maakt, configureert deze de resources dynamisch of worden de resources ingesteld op een vaste waarde die niet kan worden gewijzigd.

Onderbrekingsbeheer

Voor het beheren van onderbrekingsbeheer stellen sommige netwerkadapters verschillende onderbrekingsbeheerniveaus beschikbaar, verschillende buffersamensluitparameters (soms afzonderlijk voor verzend- en ontvangstbuffers) of beide.

Overweeg onderbrekingsbeheer voor CPU-afhankelijke workloads. Wanneer u onderbrekingsbeheer gebruikt, moet u rekening houden met de afweging tussen de cpu-besparingen en latentie van de host ten opzichte van de toegenomen CPU-besparingen voor de host vanwege meer interrupts en minder latentie. Als de netwerkadapter geen onderbrekingsbeheer uitvoert, maar wel buffersamensluiten beschikbaar maakt, kunt u de prestaties verbeteren door het aantal samengekolen buffers te verhogen om meer buffers per verzenden of ontvangen toe te staan.

Pakketverwerking met lage latentie

Veel netwerkadapters bieden opties voor het optimaliseren van door het besturingssysteem geïnduceerde latentie. Latentie is de verstreken tijd tussen het netwerkstuurprogramma dat een binnenkomend pakket verwerkt en het netwerkstuurprogramma dat het pakket terugstuurt. Deze tijd wordt meestal gemeten in microseconden. Ter vergelijking wordt de transmissietijd voor pakkettransmissies over lange afstanden meestal gemeten in milliseconden (een orde van grootte groter). Deze afstemming vermindert niet de tijd die een pakket in transit doorbrengt.

De volgende lijst bevat enkele suggesties voor het afstemmen van prestaties voor microseconden gevoelige netwerken:

• Als uw BIOS dit ondersteunt, stelt u het BIOS van de computer in op High Performance, met C-states uitgeschakeld. Sommige systemen bieden hogere prestaties als het besturingssysteem energiebeheer regelt. U kunt de energiebeheerinstellingen controleren en aanpassen vanuit energie-instellingen of met behulp van de powercfg opdracht. Zie Powercfg Command-Line Opties voor meer informatie.

• Stel het energiebeheerprofiel van het besturingssysteem in op High Performance System. Deze instelling werkt niet goed als het systeem-BIOS is ingesteld om de besturingssysteemcontrole over energiebeheer uit te schakelen.

• Statische offloads inschakelen. Schakel bijvoorbeeld de UDP-controlesommen, TCP-controlesommen en Large Send Offload (LSO)-instellingen in.

• Als het verkeer meerdere stromen heeft, bijvoorbeeld bij het ontvangen van multicast-verkeer met een hoog volume, schakelt u RSS in.

• Schakel de instelling Onderbrekingsbeheer uit voor netwerkkaartstuurprogramma's waarvoor de laagst mogelijke latentie is vereist. Houd er rekening mee dat deze configuratie meer CPU-tijd kan gebruiken en een compromis vertegenwoordigt.

• Afhandelen van netwerkadapteronderbrekingen en DPC's op een processor die de CPU-cache deelt met de kern die wordt gebruikt door het programma (gebruikers-thread) dat het pakket verwerkt. Het afstemmen van CPU-affiniteit kan worden gebruikt om een proces naar bepaalde logische processors met RSS-configuratie te leiden. Het gebruik van dezelfde kern voor de interrupt-, DPC- en gebruikersmodusthread vertoont slechtere prestaties naarmate de belasting toeneemt, omdat de ISR, DPC en thread strijden voor het gebruik van de kern.

Onderbrekingen van systeembeheer

Veel hardwaresystemen maken gebruik van SMI (System Management Interrupts) voor verschillende onderhoudsfuncties, zoals het rapporteren van ecc-geheugenfouten (foutcorrectiecode), het onderhouden van verouderde USB-compatibiliteit, het beheren van de ventilator en het beheren van door BIOS beheerde energie-instellingen.

De SMI is de interrupt met de hoogste prioriteit op het systeem en plaatst de CPU in een beheermodus. Met deze modus worden alle andere activiteiten onderbroken terwijl SMI een interrupt-serviceroutine uitvoert, meestal opgenomen in het BIOS. Helaas kan dit gedrag leiden tot latentiepieken van 100 microseconden of meer.

Als u de laagste latentie wilt bereiken, moet u een BIOS-versie aanvragen van uw hardwareprovider die SMI's tot het laagst mogelijk vermindert. Deze BIOS-versies worden vaak aangeduid als BIOS met lage latentie of het gratis BIOS van SMI. In sommige gevallen is het niet mogelijk voor een hardwareplatform om SMI-activiteit helemaal te elimineren, omdat deze wordt gebruikt om essentiële functies zoals koelventilatoren te beheren.

Het besturingssysteem kan geen controle houden over SMI's omdat de logische processor wordt uitgevoerd in een speciale onderhoudsmodus, waardoor tussenkomst van het besturingssysteem wordt voorkomen.

Automatische afstemming van TCP-ontvangstvenster

De Windows-netwerkstack maakt gebruik van een functie met de naam TCP receive window autotuning level om te onderhandelen over de grootte van het TCP-ontvangstvenster. Deze functie kan onderhandelen over een gedefinieerde ontvangstvenstergrootte voor elke TCP-communicatie tijdens de TCP-handshake en kan de prestaties van TCP-verbindingen verbeteren.

Voorheen gebruikte de Windows-netwerkstack een ontvangstvenster met een vaste grootte van 65.535 bytes dat de totale potentiële doorvoer voor verbindingen beperkt. De totale haalbare doorvoer van TCP-verbindingen kan scenario's voor netwerkgebruik beperken. Met automatische afstemming van TCP-ontvangstvensters kunnen deze scenario's volledig gebruikmaken van het netwerk.

Voor een TCP-ontvangstvenster met een bepaalde grootte kunt u de volgende vergelijking gebruiken om de totale doorvoer van één verbinding te berekenen:

Totale haalbare doorvoer in bytes = Tcp-ontvangstvenstergrootte in bytes * (1 / verbindingslatentie in seconden)

Voor een 1Gbps-verbinding met een latentie van 10 ms is de totale haalbare doorvoer bijvoorbeeld slechts 51 Mbps. Deze waarde is redelijk voor een grote bedrijfsnetwerkinfrastructuur. Door automatisch afstemmen te gebruiken om het ontvangstvenster aan te passen, kan de verbinding echter de volledige regelsnelheid van 1 Gbps bereiken.

Sommige toepassingen definiëren de grootte van het TCP-ontvangstvenster. Als de toepassing de grootte van het ontvangstvenster niet definieert, bepaalt de snelheid van de koppeling de grootte als volgt:

Op een computer waarop een 1 Gbps-netwerkadapter is geïnstalleerd, moet de venstergrootte bijvoorbeeld 64 kB zijn.

Deze functie maakt ook volledig gebruik van andere functies om de netwerkprestaties te verbeteren. Deze functies omvatten de rest van de TCP-opties die zijn gedefinieerd in RFC 1323. Windows-computers kunnen deze functies gebruiken om te onderhandelen over TCP-ontvangstvenstergrootten die kleiner zijn, maar worden geschaald op een gedefinieerde waarde, afhankelijk van de configuratie. Dit gedrag maakt de grootten gemakkelijker te verwerken voor netwerkapparaten.

Niveaus voor automatisch afstemmen

U kunt automatische afstemming van TCP-ontvangstvensters instellen op een van de vijf niveaus. Het standaardniveau is Normaal. In de volgende tabel worden de niveaus beschreven.

Als u een toepassing gebruikt om netwerkpakketten vast te leggen, moet de toepassing gegevens rapporteren die lijken op de volgende voorbeelden voor verschillende instellingen voor het automatisch afstemmen van vensters.

Niveau voor automatisch afstemmen: Normaal (standaardstatus)

In dit voorbeeld ziet u de uitvoer van een hulpprogramma voor pakketopname wanneer het automatische afstemmingsniveau van het TCP-ontvangstvenster is ingesteld op Normaal. De schaalfactor is 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:

Niveau voor automatisch afstemmen: uitgeschakeld

In dit voorbeeld ziet u de uitvoer van een hulpprogramma voor pakketopname wanneer het automatische afstemmingsniveau van het TCP-ontvangstvenster is ingesteld op Uitgeschakeld. De schaalfactor wordt niet gebruikt.

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:

Niveau voor automatisch afstemmen: beperkt

In dit voorbeeld ziet u de uitvoer van een hulpprogramma voor pakketopname wanneer het automatische afstemmingsniveau van het TCP-ontvangstvenster is ingesteld op Beperkt. De schaalfactor is 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:

Niveau voor automatisch afstemmen: zeer beperkt

In dit voorbeeld ziet u de uitvoer van een hulpprogramma voor pakketopname wanneer het automatische afstemmingsniveau van tcp-ontvangstvenster is ingesteld op Zeer beperkt. De schaalfactor is 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:

Niveau voor automatisch afstemmen: experimenteel

In dit voorbeeld ziet u de uitvoer van een hulpprogramma voor pakketopname wanneer het automatische afstemmingsniveau van het TCP-ontvangstvenster is ingesteld op Experimenteel. De schaalfactor is 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:

Het automatische afstemmingsniveau van TCP-ontvangstvenster controleren en configureren

U kunt Windows PowerShell-cmdlets of de Windows-opdracht netsh gebruiken om het automatische afstemmingsniveau voor TCP-ontvangstvensters te controleren of te wijzigen.

Windows-filterplatform

Windows Filtering Platform (WFP), geïntroduceerd in Windows Server 2008, biedt API's aan niet-Microsoft onafhankelijke softwareleveranciers (ISV's) om pakketverwerkingsfilters te maken. Met WFP kan software van derden netwerkverkeer inspecteren, wijzigen of filteren op verschillende lagen van de netwerkstack. Hoewel deze functionaliteit essentieel is voor beveiligingstoepassingen, kan dit leiden tot prestatieoverhead als deze niet correct wordt geïmplementeerd. Voorbeelden hiervan zijn firewall- en antivirussoftware.

Een slecht geschreven WFP-filter kan de netwerkprestaties van een server aanzienlijk verminderen. Zie Porting Packet-Processing Drivers and Apps to WFP (Stuurprogramma's en apps overzetten naar WFP ) in het Windows-ontwikkelaarscentrum voor meer informatie.

Verouderde TCP-parameters

De volgende registerinstellingen van Windows Server 2003 worden niet meer ondersteund en worden genegeerd in latere versies.

• TcpWindowSize
• NumTcbTablePartitions
• MaxHashTableSize

Al deze instellingen bevinden zich in de volgende registersubsleutel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters