Wat veroorzaakt pakketverlies alleen tijdens grote schrijfacties op een thuis-NAS?

Pakketverlies tijdens grote NAS-schrijfacties wijst meestal op een zwakte in het netwerkpad van client naar NAS bij langdurige belasting, niet alleen op de schijven zelf.

Een korte ping of directory-browse kan schoon blijven omdat het weinig verkeer genereert, terwijl een multi-gigabyte SMB-schrijfactie de client continu laat verzenden, switch-queues vult, de kabel op lijnsnelheid belast en de NAS NIC en CPU dwingt om continu te ontvangen. De diagnose moet daarom idle en belaste metingen vergelijken, de schrijfrichting hop voor hop volgen en telkens één kabel, poort, driverfunctie of verzenderconditie veranderen.

Bewijs dat het verlies alleen optreedt onder de schrijflast

Voer een continue kleine ping uit van de schrijvende client naar de NAS vóór de kopie, tijdens een langdurige grote-bestandsschrijfactie en nadat de kopie stopt. Registreer tegelijkertijd SMB-doorvoer, belaste latentie, retransmissies en interface-foutentellers op beide eindpunten.

Testen op pakketverlies moet ping, iperf en interface-statistieken combineren omdat een enkele ping van vier pakketten een kort door belasting veroorzaakte storing kan missen. Het nuttige patroon is of verlies of fouten beginnen met de schrijfactie en verdwijnen wanneer de schrijfactie stopt.

Als alleen de latentie stijgt terwijl pakketten uiteindelijk terugkeren, onderzoek dan wachtrijen en bufferbloat voordat je het pakketverlies noemt. Als de NAS-opslag pauzeert maar pings en interface-tellers schoon blijven, is de bottleneck waarschijnlijker het schrijfpad, bestandssysteem, cache flush, pariteit of applicatie dan de Ethernet-levering.

Volg de schrijfrichting voordat je hardware verwisselt

Tijdens een client-naar-NAS schrijfactie is de client NIC de zender, de switch stuurt door naar de NAS-poort en de NAS NIC is de ontvanger. Die richting vertelt je welke tellers en vervangingen daadwerkelijk de fout kunnen isoleren.

Een schone NAS-transmit-teller maakt de NAS-ontvangstzijde niet schoon, en een schone client-ontvangstteller zegt weinig over frames die de client verlaten. Vergelijk client TX-fouten en drops, switch ingress- en egress-tellers, NAS RX-fouten en drops, en TCP-retransmissies over hetzelfde testinterval.

Reset of registreer de tellers vóór elke test, transfer hetzelfde grote bestand en bereken welke teller alleen tijdens de storing toeneemt. Het eerste apparaat dat fysieke fouten, queue discards, gemiste pakketten of ontvangst drops registreert, wordt het volgende testpunt.

Controleer of fysieke fouten toenemen bij aanhoudende lijnsnelheid

Een marginale kabel, connector, transceiver of switch-poort kan licht verkeer doorlaten en toch CRC-, frame-, carrier- of symboolfouten accumuleren tijdens een lange schrijfactie. Grote transfers “overbelasten” een correct onderhandelde kabel niet; ze creëren simpelweg genoeg frames om een zwak fysiek pad snel te onthullen.

Praktijkgevallen van bestandoverdracht laten zien dat interfacefouten tijdens grote kopieën wijzen op de kabel, NIC, poort of tussenliggende apparatuur in plaats van op de bestandsgrootte zelf.

Vervang per test slechts één component: eerst de patchkabel, dan de switch-poort, vervolgens de client-adapter of NAS-poort indien mogelijk. Een diagnose op fysiek niveau wordt ondersteund wanneer de fouttoename één component volgt of verdwijnt na die enkele vervanging.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controleer of de NAS-ontvanger frames verliest voordat SMB ze kan verwerken

Het netwerk kan elektrisch schoon zijn terwijl de ontvangende host toch pakketten verliest omdat de NIC-queues, driver, interruptafhandeling, CPU of virtuele switch de aankomsnelheid niet aankan. Dit is vooral aannemelijk bij een kleine NAS die encryptie, containers, indexering of pariteitswerk uitvoert tijdens het schrijven.

Een direct geval van high-speed Ethernet beschrijft host-pakketverwerkings-overbelasting zelfs zonder een congestief multi-hop netwerk. Het belangrijkste verschil is dat host RX drops of gemiste-pakket-tellers toenemen terwijl kabel CRC-tellers schoon blijven.

Herhaal de schrijfactie met niet-essentiële NAS-diensten gepauzeerd en test vervolgens een geheugen-naar-geheugen netwerkbelasting die schijf-schrijfacties uitsluit. Als ontvangst drops blijven zonder opslag I/O, richt je dan op de NIC-driver, queue-diepte, interruptverdeling, virtuele switch en host-CPU in plaats van het bestandssysteem.

Zoek naar microbursts bij een langzamere of gedeelde uitgaande poort

Pakketverlies kan optreden binnen de switch wanneer een snellere client naar een langzamere NAS-poort zendt, meerdere clients tegelijk schrijven, of verkeer van meerdere inkomende poorten samenkomt in één uitgaande wachtrij. Gemiddeld gebruik kan veilig lijken terwijl een korte piek de wachtrijcapaciteit overschrijdt.

Een voorbeeld van opslag-schrijfactie met microburst pakketverlies toont hoe twee zenders met hoge snelheid tijdelijk meer uitgaande bandbreedte en bufferruimte kunnen vereisen dan de bestemmingspoort biedt.

Test één zender via één switch en vergelijk dan een directe verbinding of een pad met gelijke linksnelheden. Als verlies verdwijnt wanneer concurrerende zenders, een langzamere uplink of de tussenliggende switch wordt verwijderd, inspecteer dan uitgaande discards en wachtrijgedrag in plaats van de NAS-schijven te vervangen.

Test EEE en offloads alleen nadat de fout is gelokaliseerd

Energy Efficient Ethernet, checksum offload, large-send offload, flow control en interrupt moderation kunnen specifieke NIC- en drivercombinaties beïnvloeden, maar het uitschakelen van alle functies tegelijk vernietigt het bewijs dat nodig is om de echte oorzaak te identificeren.

Een gedocumenteerd Raspberry Pi Ethernet-probleem vond dat het uitschakelen van Energy Efficient Ethernet ernstig pakketverlies stopte voor die controller en linkpartner. Dit is een nuttige A/B-test alleen nadat tellers of vervangingen naar het eindpunt wijzen in plaats van naar de kabel of switch-queue.

Verander één functie, herhaal dezelfde grote schrijfactie en herstel de oorspronkelijke instelling als het resultaat niet verandert. Een driver-functie workaround moet worden gedocumenteerd met het adaptermodel, driver-versie, switch-poort en exact symptoom zodat een latere update kan worden getest in plaats van onverklaarde tuning te laten staan.

Gebruik het resultaatpatroon om de volgende reparatie te kiezen

De uiteindelijke diagnose moet uitleggen waarom klein verkeer schoon blijft en langdurige schrijfacties falen. Fysieke fouten wijzen op een signaalpadprobleem; switch-uitgaande discards wijzen op wachtrijdruk; NAS RX drops wijzen op ontvanger-overbelasting; en schone netwerk-tellers met een vastgelopen kopie wijzen terug naar opslag- of applicatiegedrag.

De uitleg van ZimaSpace over hoe pakketverlies nuttige doorvoer verlaagt helpt te interpreteren waarom de onderhandelde link op volle snelheid kan blijven terwijl de SMB-schrijfactie vertraagt, pauzeert of herhaaldelijk retransmitteert.

Verklaar het probleem niet opgelost totdat dezelfde grote schrijfactie herhaaldelijk voltooid wordt met stabiele latentie, nul nieuwe fysieke fouten, geen groeiende ontvangst drops of uitgaande discards en een intacte bestemmingschecksum. Als het bewijs het netwerk niet kan onderscheiden van het opslagpad, stop dan met instellingen wijzigen en voer de test opnieuw uit zonder schijf I/O.