Prestandajustering för nätverkskort i Windows Server

I den här artikeln beskrivs hur du optimerar nätverkskortprestanda i Windows Server-miljöer. Prestandajustering för nätverkskort kan avsevärt förbättra dataflödet, minska svarstiden och maximera resursanvändningen för dina serverarbetsbelastningar.

Rätt justeringsinställningar för nätverkskorten beror på följande variabler:

• Nätverkskortet och dess funktionsuppsättning
• Den typ av arbetsbelastning som servern utför
• Servermaskinvara och programvaruresurser
• Dina prestandamål för servern

De optimala justeringsinställningarna beror på din specifika maskinvarukonfiguration, arbetsbelastningskrav och prestandamål. Innan du implementerar ändringar utvärderar du dina aktuella nätverksprestanda och identifierar förbättringsområden. Vissa funktioner och inställningar kan variera mellan olika versioner.

I följande avsnitt beskrivs några av dina alternativ för prestandajustering.

Avlastningsfunktioner

Nätverksbelastningsfunktioner överför bearbetningsuppgifter från processorn till nätverkskortmaskinvaran, vilket minskar systemets omkostnader och förbättrar den övergripande nätverksprestandan. Vanliga avlastningsfunktioner inkluderar TCP-kontrollsumnas avlastning, stor sändningsavlastning (LSO) och avlastning av mottagningens sidskalning (RSS).

Det är vanligtvis fördelaktigt att aktivera avlastningsegenskaper för nätverkskort. Nätverkskortet kanske dock inte är tillräckligt kraftfullt för att hantera avlastningsfunktionerna med högt dataflöde. Överväg till exempel ett nätverkskort med begränsade maskinvaruresurser. I så fall kan aktivering av segmenterings avlastningsfunktioner minska det maximala hållbara dataflödet för adaptern. Men om det minskade dataflödet är acceptabelt bör du aktivera funktionerna för segmenterings avlastning.

Vissa nätverkskort kräver att du aktiverar avlastningsfunktioner oberoende av sökvägarna för att skicka och ta emot.

Skalning på mottagarsidan (RSS) för webbservrar

RSS kan förbättra webbskalbarhet och prestanda när det finns färre nätverkskort än logiska processorer på servern. När all webbtrafik går via DE RSS-kompatibla nätverkskorten kan servern bearbeta inkommande webbbegäranden från olika anslutningar samtidigt över olika processorer.

RSS-profiler och RSS-köer

Den fördefinierade RSS-standardprofilen är NUMAStatic. Innan du börjar använda RSS-profiler granskar du de tillgängliga profilerna för att förstå när de är fördelaktiga och hur de gäller för din nätverksmiljö och maskinvara.

Öppna till exempel Aktivitetshanteraren och granska de logiska processorerna på servern. Om de verkar vara underutnyttjarda för att ta emot trafik kan du försöka öka antalet RSS-köer från standardvärdet två till det högsta som ditt nätverkskort stöder. Nätverkskortet kan ha alternativ för att ändra antalet RSS-köer som en del av drivrutinen.

Resurser för nätverksadapter

För nätverkskort som gör att du kan konfigurera resurser manuellt, till exempel ta emot och skicka buffertar, bör du öka de allokerade resurserna.

Vissa nätverkskort ställer in sina mottagningsbuffertar lågt för att spara det minne som allokerats av värddatorn. Det låga värdet resulterar i borttagna paket och sämre prestanda. För mottagningsintensiva scenarier rekommenderar vi därför att du ökar värdet för mottagningsbufferten till det högsta värdet.

Om ett nätverkskort inte exponerar manuell resurskonfiguration konfigureras resurserna dynamiskt eller så är resurserna inställda på ett fast värde som inte kan ändras.

Avbrottsmoderering

För att styra avbrottsmoderering exponerar vissa nätverkskort olika nivåer för avbrottsmoderering, olika buffertsambandsparametrar (ibland separat för att skicka och ta emot buffertar) eller båda.

Du bör överväga avbrottsmoderering för CPU-bundna arbetsbelastningar. När du använder avbrottsmoderering bör du överväga kompromissen mellan processorbesparingarna för värden och svarstiden jämfört med de ökade processorbesparingarna för värden på grund av fler avbrott och mindre svarstid. Om nätverkskortet inte utför avbrottsmoderering, men det exponerar buffertsamband, kan du förbättra prestandan genom att öka antalet sammanflätade buffertar så att fler buffertar tillåts per sändning eller mottagning.

Paketbearbetning med låg svarstid

Många nätverkskort ger alternativ för att optimera svarstid som orsakas av operativsystemet. Svarstiden är den förflutna tiden mellan nätverksdrivrutinen som bearbetar ett inkommande paket och nätverksdrivrutinen som skickar tillbaka paketet. Den här tiden mäts vanligtvis i mikrosekunder. Som jämförelse mäts överföringstiden för paketöverföringar över långa avstånd vanligtvis i millisekunder (en storleksordning som är större). Den här justeringen minskar inte den tid ett paket spenderar under överföring.

Följande lista innehåller några förslag på prestandajustering för mikrosekunderskänsliga nätverk:

• Om DIN BIOS stöder det ställer du in datorns BIOS på Hög prestanda med C-states inaktiverad. Vissa system ger högre prestanda om operativsystemet styr energisparfunktionerna. Du kan kontrollera och justera energisparinställningarna från energisparinställningar eller med hjälp powercfg av kommandot . Mer information finns i Powercfg Command-Line Alternativ.

• Ange operativsystemets energisparprofil till System med höga prestanda. Den här inställningen fungerar inte korrekt om systemets BIOS är inställt på att inaktivera operativsystemets kontroll av energisparfunktioner.

• Aktivera statiska avlastningar. Aktivera till exempel inställningarna UDP Checksums, TCP Checksums och Send Large Offload (LSO).

• Om trafiken består av flera dataströmmar, till exempel när du tar emot stora mängder multicast-trafik, aktivera RSS.

• Inaktivera inställningen Avbrottsmoderering för nätverkskortdrivrutiner som kräver lägsta möjliga svarstid. Kom ihåg att den här konfigurationen kan använda mer CPU-tid och representerar en kompromiss.

• Hantera nätverkskortavbrott och DPC:er på en kärnprocessor som delar CPU-cache med den kärna som används av programmet (användartråden) som hanterar paketet. Processortillhörighetsjustering kan användas för att dirigera en process till vissa logiska processorer med RSS-konfiguration. Att använda samma kärna för avbrottshantering, DPC och användarlägestråd visar sämre prestanda när belastningen ökar eftersom ISR, DPC och användarlägestråd konkurrerar om att använda kärnan.

Systemhanteringsavbrott

Många maskinvarusystem använder systemhanteringsavbrott (SMI) för olika underhållsfunktioner, till exempel rapportera felkorrigeringskod (ECC) minnesfel, upprätthålla äldre USB-kompatibilitet, kontrollera fläkten och hantera BIOS-kontrollerade energiinställningar.

SMI är det högsta prioritetsavbrottet i systemet och placerar processorn i ett hanteringsläge. Det här läget föregriper all annan aktivitet medan SMI kör en avbrottstjänstrutin, vanligtvis i BIOS. Tyvärr kan det här beteendet resultera i svarstidstoppar på 100 mikrosekunder eller mer.

Om du behöver uppnå den lägsta svarstiden bör du begära en BIOS-version från maskinvaruleverantören som minskar SMIs till lägsta möjliga grad. Dessa BIOS-versioner kallas ofta för BIOS med låg latens eller SMI free BIOS. I vissa fall är det inte möjligt för en maskinvaruplattform att helt eliminera SMI-aktiviteten eftersom den används för att styra viktiga funktioner som kylnings fläktar.

Operativsystemet kan inte styra SME:er eftersom den logiska processorn körs i ett särskilt underhållsläge, vilket förhindrar åtgärder i operativsystemet.

Automatisk tunning av TCP-mottagningsfönster

Windows-nätverksstacken använder en funktion med namnet TCP-fönstrets autotuningsnivå för att förhandla om storleken på TCP-mottagningsfönstret. Den här funktionen kan förhandla fram en definierad mottagningsfönsterstorlek för varje TCP-kommunikation under TCP-handskakningen och kan optimera prestandan för TCP-anslutningar.

Tidigare använde Windows-nätverksstacken ett mottagningsfönster med fast storlek på 65 535 byte som begränsade det totala potentiella dataflödet för anslutningar. Det totala möjliga dataflödet för TCP-anslutningar kan begränsa nätverksanvändningsscenarier. Med autotuning av TCP-mottagningsfönstret kan dessa scenarier använda nätverket fullt ut.

För ett TCP-mottagningsfönster som har en viss storlek kan du använda följande ekvation för att beräkna det totala dataflödet för en enda anslutning:

Totalt uppnåeligt dataflöde i byte = TCP tar emot fönsterstorlek i byte * (1/ anslutningsfördröjning i sekunder)

För en anslutning på 1 Gbit/s som har en svarstid på 10 ms är det totala uppnåeliga dataflödet bara 51 Mbit/s. Det här värdet är rimligt för en stor företagsnätverksinfrastruktur. Men genom att använda autotuning för att justera mottagningsfönstret kan anslutningen uppnå en fullständig linjehastighet på 1 Gbit/s.

Vissa program definierar storleken på TCP-mottagningsfönstret. Om programmet inte definierar storleken på mottagningsfönstret avgör länkhastigheten storleken enligt följande:

På en dator som till exempel har ett nätverkskort på 1 Gbit/s installerat bör fönsterstorleken vara 64 kB.

Den här funktionen använder även andra funktioner fullt ut för att förbättra nätverksprestanda. Dessa funktioner omfattar resten av de TCP-alternativ som definieras i RFC 1323. Windows-baserade datorer kan använda dessa funktioner för att avtala TCP-mottagningsfönsterstorlekar som är mindre men skalas enligt ett definierat värde, beroende på konfigurationen. Det här beteendet gör storlekarna enklare att hantera för nätverksenheter.

Automatiska tunningsnivåer

Du kan ställa in automatisk tunning av TCP-mottagningsfönstret till någon av fem nivåer. Standardnivån är Normal. I följande tabell beskrivs nivåerna.

Om du använder ett program för att samla in nätverkspaket bör programmet rapportera data som liknar följande exempel för olika inställningar för automatisk tunning av fönster.

Automatisk tunningsnivå: Normal (standardtillstånd)

I det här exemplet visas utdata från ett paketinsamlingsverktyg när autotuningsnivån för TCP-mottagningsfönstret är inställd på Normal. Skalningsfaktorn är 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:

Automatisk tunningsnivå: Inaktiverad

Det här exemplet visar utdata från ett paketinsamlingsverktyg när autotuningsnivån för TCP-mottagningsfönstret är inställd på Inaktiverad. Skalningsfaktorn används inte.

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:

Automatisk tunningsnivå: Begränsad

I det här exemplet visas utdata från ett paketinsamlingsverktyg när autotuningsnivån för TCP-mottagningsfönstret är inställd på Begränsad. Skalningsfaktorn är 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:

Automatisk tunningsnivå: Mycket begränsad

Det här exemplet visar utdata från ett paketinsamlingsverktyg när autotuningsnivån för TCP-mottagningsfönstret är inställd på Strikt begränsad. Skalningsfaktorn är 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:

Automatisk tunningsnivå: Experimentell

Det här exemplet visar utdata från ett paketinsamlingsverktyg när autotuningsnivån för TCP-mottagningsfönstret är inställd på Experimentell. Skalningsfaktorn är 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:

Granska och konfigurera automatisk tunningsnivå för TCP-mottagningsfönster

Du kan använda antingen Windows PowerShell-cmdletar eller netsh Windows-kommandot för att granska eller ändra autotuningsnivån för TCP-mottagningsfönstret.

Windows-filtreringsplattform

Windows Filtering Platform (WFP), som introducerades i Windows Server 2008, tillhandahåller API:er till icke-Microsoft-oberoende programvaruleverantörer (ISV:er) för att skapa paketbearbetningsfilter. Med WFP kan programvara från tredje part inspektera, ändra eller filtrera nätverkstrafik i olika lager i nätverksstacken. Även om den här funktionen är viktig för säkerhetsprogram kan den medföra prestandaomkostnader om den inte implementeras korrekt. Exempel är brandvägg och antivirusprogram.

Ett dåligt skrivet WFP-filter kan avsevärt minska serverns nätverksprestanda. Mer information finns i Porting Packet-Processing Drivers and Apps to WFP i Windows Dev Center.

Inaktuella TCP-parametrar

Följande registerinställningar från Windows Server 2003 stöds inte längre och ignoreras i senare versioner.

• TcpWindowSize
• NumTcbTablePartitions
• MaxHashTableSize

Alla dessa inställningar fanns i följande registerundernyckel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters