Kända problem med TCP/IP-prestanda

Kommentar

Den här artikeln ingår i en serie i tre delar. Du kan granska del 1: Översikt över TCP/IP-prestanda och del 2: Problem med underliggande TCP/IP-prestanda för underliggande nätverk.

I den här artikeln beskrivs följande problem med TCP/IP-prestanda:

• Långsamt dataflöde i nätverk med hög fördröjning och hög bandbredd
• Långsamt dataflöde i nätverk med låg fördröjning och hög bandbredd
• Underliggande nätverksproblem

Långsam dataflödeshastighet i ett nätverk med hög svarstid och bandbredd

Två servrar som finns på olika platser är anslutna via ett nätverk med långa svarstider. Dataflödet som mäts med ctsTraffic-verktyget är lägre än baslinjen.

Det beror på att alternativet TCP-fönsterskalning inte är aktiverat på någon av servrarna. Använd Windows-kommandotolken eller Windows PowerShell för att aktivera alternativet genom att ange autotuningsnivån för TCP-mottagningsfönstret.

Använd kommandotolken för att aktivera automatisk tunningsnivå

Kör följande kommando:

netsh int tcp set global autotuninglevel=normal 

Om du vill kontrollera om autotuningsnivån är aktiverad använder du följande kommando:

netsh int tcp show global

Använda PowerShell för att aktivera nivån för automatisk justering

Kör följande cmdlet:

Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

Om du vill kontrollera om autotuningsnivån är aktiverad använder du följande cmdlet:

Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*

Kommentar

Det finns fem nivåer för automatisk mottagningsfönster: Inaktiverad, Strikt begränsad, Begränsad, Normal och Experimentell. Mer information om hur automatisk tunning påverkar dataflödet finns i Prestandajustering av nätverkskort.

Långsam dataflödeshastighet på ett nätverk med låg svarstid och hög bandbredd

Två servrar är anslutna i samma nätverk som har låg svarstid och hög bandbredd. När du skapar en baslinje eller testar TCP-prestanda med ctsTraffic-verktyget är det bara CPU 0-toppar på en processorserver med flera kärnor.

Det här problemet beror på att funktionen RSS (Receive Side Scaling) eller Virtual Machine Queue (VMQ) inte är aktiverad eller inte är korrekt konfigurerad. Använd VMQ när den fysiska datorn är en hypervisor-dator. Om det inte är det aktiverar du RSS både på operativsystemet (OS) och på nätverkskorten.

Kommentar

Trådlösa nätverkskort stöder inte RSS- eller VMQ-funktioner.

Aktivera RSS för OS

Aktivera RSS med kommandotolken eller PowerShell på följande sätt:

Kommandotolk: netsh int tcp set global rss=enabled

PowerShell: Set-NetAdapterRss -Name <interface name> -Enabled $True

Aktivera RSS för nätverkskort

Kontrollera först om RSS-funktionen är aktiverad. Kontrollera de avancerade egenskaperna för nätverkskortet för den relaterade konfigurationen med hjälp av följande cmdlet:

Get-NetAdapterAdvancedProperty | Where-Object -property RegistryKeyword -Like *rss* | format-table -AutoSize

Kommentar

Ändringar av de avancerade egenskaperna kan leda till avbrott eller förlust av nätverksanslutning. Innan du gör ändringarna kan du läsa NIC-leverantörsdokumentationen.

Följ dessa steg för att aktivera RSS för nätverkskort:

1. Kör ncpa.cpl för att öppna nätverksanslutningar.
2. Högerklicka på målanslutningen och välj sedan Egenskaper>Konfigurera.
3. Under fliken Avancerat letar du reda på Ta emot sidoskalning i egenskapslistan och anger sedan Värdet till Aktivera.
4. Välj OK.

RSS kan också aktiveras med hjälp av PowerShell-cmdleten:

Set-NetAdapterAdvancedProperty -Name <Interface name> -RegistryKeyword *RSS -RegistryValue 1

Underliggande nätverksproblem

Det här avsnittet beskriver hur du söker efter underliggande nätverksproblem när du mäter en dataflödesbaslinje eller felsöker dataflödesproblem.

Om du vill få en logganalys på paketnivå kontrollerar du underliggande nätverksproblem med hjälp av ett verktyg för insamling av nätverkspaket (till exempel Microsoft Network Monitor, Wireshark eller ctsTraffic).

Steg för att utföra loggar med verktyg för insamling av nätverkspaket

1. Börja logga med Microsoft Network Monitor eller Wireshark för att samla in trafik på båda slutpunkterna. Du kan också använda det inbyggda infångningsverktyget för Windows på följande sätt:

   1. Öppna Kommandotolken som administratör.

   2. Kör följande kommando:

      NETSH TRACE START CAPTURE=YES REPORT=DISABLED TRACEFILE=<FILEPATH>.ETL MAXSIZE=512
      

      Kommentar

      Flera avbildningar kan krävas när kommandot används netsh trace .

2. Kör verktyget CTStraffic.exe för att generera en .csv fil.

3. Stoppa loggningen. För det inbyggda avbildningsverktyget i Windows skriver du NETSH TRACE STOP i Kommandotolken som administratör.

Analysera avbildningsfilen

Här är ett exempel som visar hur du analyserar ett filtrerat resultat. I det här scenariot använder verktyget ctsTraffic push-mönstret (standardmönstret), vilket innebär att paketet skickas från klienten till servern.

1. Öppna avbildningsfilen i Microsoft Network Monitor.

2. Filtrera nätverksspårningen Property.TCPRetransmit==1 && tcp.Port==4444 med hjälp av filtret, som letar upp överföringspaketen. En paketöverföring innebär att en TCP-bekräftelse av den angivna TCP-sekvensen från avsändaren aldrig tas emot.

   Kommentar

   Om du vill analysera en ETL-fil går du till Verktygsalternativ>>Parsningsprofiler>Windows>Set As Active>OK.

   

   Som du ser i skärmbilden överförs bildrutan #441 två gånger, vilket innebär att den skickas av avsändaren tre gånger. Använd samma TCP-sekvensnummer (2278877548) för att identifiera den här ramen.

3. Högerklicka på SequenceNumber i Raminformation och välj Lägg till markerat värde i visningsfiltret.

   

4. Inaktivera föregående filter genom att lägga till "//" på följande sätt:

   

5. Välj Använd. Den fullständiga TCP-sekvensen med det här sekvensnumret visas på följande sätt:

   

   Det här resultatet visar att den ursprungliga ramen #441 inte tas emot av servern och överförs på nytt av avsändaren. Återöverföringen av en ram sker om ingen bekräftelse av sekvensen tas emot. Information om hur TCP fungerar finns i Trevägshandskakning via TCP/IP och Beskrivning av Windows TCP-funktioner. Kopiera TCP.SequenceNumber == <value> sedan sekvensfiltret från klientspårningen och klistra in det på serverspårningen.

   På servern tas endast ett paket av den angivna sekvensen emot, vilket visas i följande resultat:

   

   Det här resultatet visar att det finns paketförlust från avsändaren till mottagaren på mellanliggande nätverksenheter. Paketen lämnar avsändaren men når aldrig mottagaren. Det är ett problem med underliggande nätverk och det bör lösas av nätverksadministratörer.

Prestanda för TCP-loopback

Med lanseringen av Windows Server 2019 har modellen för bearbetning av TCP/IP-loopback ändrats för att hantera vissa flaskhalsar för prestanda som fanns i tidigare windows-versioner. I det här avsnittet beskrivs de konfigurationsalternativ som är tillgängliga för att ändra beteendet för bearbetning av TCP/IP-loopback.

Konfigurationsparametrarna är tillgängliga via netsh-konfigurationsverktyget. Varje inställning kan anges individuellt för IPv4 och IPv6. Standardvärdena kan variera från olika Windows-versioner.

Kommentar

På Windows-datorer för generell användning bör standardvärdena inte ändras.

Om en programutvecklare fastställer att loopback-datasökvägen är rotorsaken till att programmen inte har tillräcklig prestanda kan följande kommandon användas för att skräddarsy konfigurationen efter programmets individuella behov.

netsh int ipv6|ipv4 set gl loopbackexecutionmode=adaptive|inline|worker
netsh int ipv6|ipv4 set gl loopbackworkercount=<value>
netsh int ipv6|ipv4 set gl loopbacklargemtu=enable|disable

Förklaring

Loopbackexecutionmode
Worker

I det här läget placeras paket i kö på avsändarsidan och bearbetas av en arbetstråd på mottagarsidan. Det här läget gynnar dataflödet framför svarstiden.

Inline

I det här läget utförs bearbetningen i samband med programtrådar både på avsändar- och mottagarsidan. Det här läget gynnar svarstid över dataflödet.

Adaptive

De första paketen i dataflödet bearbetas infogade och sedan skjuts paketen upp till arbetstrådar. Det här läget försöker balansera svarstid och dataflöde.

Loopbackworkercount

Gör det möjligt att konfigurera antalet arbetstrådar som har använts.

Loopbacklargemtu

Tillåter att du konfigurerar användningen av stor MTU. Detta bör vara aktiverat.