Vad orsakar paketförlust endast vid stora skrivningar till hemmets NAS?
Packetförlust vid stora NAS-skrivningar avslöjar vanligtvis en svaghet i nätverksvägen mellan klient och NAS under belastning, inte bara i diskarna.
En kort ping eller katalogbläddring kan förbli ren eftersom den genererar lite trafik, medan en SMB-skrivning på flera gigabyte håller klienten igång, fyller switchens köer, belastar kabeln i linjetakt och tvingar NAS:s nätverkskort och CPU att ta emot kontinuerligt. Diagnosen bör därför jämföra mätningar i vila och under belastning, följa skrivriktningen hopp för hopp, och byta en kabel, port, drivrutinsfunktion eller sändarförhållande i taget.
Bevisa att förlusten endast uppstår under skrivbelastning
Kör en kontinuerlig liten ping från skrivande klient till NAS före kopieringen, under en långvarig storfilsskrivning och efter att kopieringen stoppats. Samtidigt, registrera SMB-genomströmning, belastad latens, omöverföringar och gränssnitts-felräknare på båda ändpunkterna.
Testning av packetförlust bör kombinera ping, iperf och gränssnittsstatistik eftersom en enstaka fyrpaketsping kan missa ett kortvarigt fel som triggas av belastning. Det användbara mönstret är om förlust eller fel börjar med skrivningen och försvinner när skrivningen stoppas.
Om endast latensen ökar medan paketen så småningom återkommer, undersök köhantering och bufferbloat innan du kallar det packetförlust. Om NAS-lagringen pausar men pingar och gränssnitts-räknare förblir rena är flaskhalsen troligen skrivvägen, filsystemet, cache-flush, paritet eller applikationen snarare än Ethernet-leveransen.
Följ skrivriktningen innan du byter hårdvara
Under en klient-till-NAS-skrivning är klientens nätverkskort sändaren, switchen vidarebefordrar mot NAS-porten och NAS:s nätverkskort är mottagaren. Den riktningen visar vilka räknare och byten som faktiskt kan isolera felet.
En ren NAS-sändarräknare rensar inte NAS-mottagarsidan, och en ren klientmottagarräknare säger lite om ramar som lämnar klienten. Jämför klientens TX-fel och droppar, switchens ingångs- och utgångsräknare, NAS RX-fel och droppar samt TCP-omöverföringar under samma testintervall.
Återställ eller registrera räknarna före varje körning, överför samma stora fil och beräkna sedan vilken räknare som ökar endast under felet. Den första enheten som registrerar fysiska fel, köavvisningar, missade paket eller mottagningsdroppar blir nästa testpunkt.
Kontrollera om fysiska fel ökar vid konstant linjetakt
En marginal kabel, kontakt, transceiver eller switchport kan klara lätt trafik men ändå samla på sig CRC-, ram-, bärare- eller symbolfel under en lång skrivning. Stora överföringar "överbelastar" inte en korrekt förhandlad kabel; de skapar helt enkelt tillräckligt med ramar för att snabbt avslöja en svag fysisk väg.
Verkliga felsökningsfall visar att gränssnitts-fel under stora kopieringar pekar mot kabeln, nätverkskortet, porten eller mellanliggande utrustning snarare än filstorleken i sig.
Byt endast en komponent per körning: först patchkabeln, sedan switchporten, och sedan klientadaptern eller NAS-porten när det är möjligt. En diagnos på fysisk nivå stöds när felökningen följer en komponent eller försvinner efter det bytet.
Kontrollera om NAS-mottagaren tappar ramar innan SMB kan bearbeta dem
Nätverket kan vara elektriskt rent medan den mottagande värden ändå förlorar paket eftersom dess nätverkskorts-köer, drivrutin, avbrottshantering, CPU eller virtuella switch inte kan hantera ankomsttakten. Detta är särskilt troligt på en liten NAS som kör kryptering, containers, indexering eller paritetsarbete under skrivningen.
En direkt hög-hastighets Ethernet-fall beskriver överbelastning av värdens paketbearbetning även utan ett överbelastat multi-hop-nätverk. Den viktiga skillnaden är att värdens RX-droppar eller räknare för missade paket ökar medan kabelns CRC-räknare förblir rena.
Upprepa skrivningen med icke nödvändiga NAS-tjänster pausade, testa sedan en minne-till-minne nätverksbelastning som tar bort disk-skrivningar. Om mottagningsdroppar kvarstår utan lagrings-I/O, fokusera på nätverkskortets drivrutin, ködjup, avbrottsfördelning, virtuell switch och värdens CPU snarare än filsystemet.
Letar efter mikroutbrott vid en långsammare eller delad utgångsport
Packetförlust kan uppstå inuti switchen när en snabbare klient skickar mot en långsammare NAS-port, flera klienter skriver samtidigt eller trafik från flera ingångsportar konvergerar till en utgångskö. Genomsnittlig användning kan se säker ut även om ett kort utbrott överskrider kökapaciteten.
Exempel på lagringsskrivning med mikroutbrottspacketförlust visar hur två hög-hastighets-sändare kortvarigt kan kräva mer utgångsbandbredd och buffertutrymme än destinationsporten tillhandahåller.
Testa en sändare genom en switch, jämför sedan en direktanslutning eller en väg med lika länkhastigheter. Om förlust försvinner när konkurrerande sändare, en långsammare uplink eller mellanliggande switch tas bort, inspektera utgångsavvisningar och köbeteende istället för att byta NAS-diskarna.
Testa EEE och offloads först efter att felet lokaliserats
Energy Efficient Ethernet, checksum offload, large-send offload, flödeskontroll och avbrottsmodulering kan påverka specifika nätverkskort och drivrutinskombinationer, men att inaktivera alla funktioner samtidigt förstör bevisen som behövs för att identifiera den verkliga orsaken.
En dokumenterad Raspberry Pi Ethernet-fråga visade att inaktivering av Energy Efficient Ethernet stoppade allvarlig packetförlust för den kontrollern och länkpartnern. Detta är ett användbart A/B-test först efter att räknare eller byten pekar på ändpunkten snarare än kabeln eller switchkön.
Byt en funktion, upprepa samma stora skrivning och återställ ursprunglig inställning om resultatet inte ändras. En drivrutins-funktionslösning bör dokumenteras med adaptermodell, drivrutinsversion, switchport och exakt symptom så att en senare uppdatering kan testas istället för att lämna oförklarad justering kvar.
Använd resultatmönstret för att välja nästa reparation
Den slutgiltiga diagnosen bör förklara varför liten trafik förblir ren medan långvariga skrivningar misslyckas. Fysiska fel indikerar ett signalvägsproblem; switchens utgångsavvisningar indikerar kötryck; NAS RX-droppar indikerar mottagaröverbelastning; och rena nätverksräknare med en fastfrusen kopia pekar tillbaka på lagring eller applikationsbeteende.
ZimaSpace’s förklaring av hur packetförlust minskar användbar genomströmning hjälper till att tolka varför den förhandlade länken kan förbli i full hastighet medan SMB-skrivningen saktar ner, pausar eller upprepade gånger omöverför.
Utropa inte problemet som löst förrän samma stora skrivning slutförs upprepade gånger med stabil latens, noll nya fysiska fel, inga ökande mottagningsdroppar eller utgångsavvisningar och en intakt destinationskontrollsumma. Om bevisen inte kan skilja nätverket från lagringsvägen, sluta ändra inställningar och kör om testet utan disk-I/O.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
