Varför sjunker USB-säkerhetskopieringshastigheten efter de första 50 GB av en enda sammanhängande överföring?
Hastigheten vid USB-säkerhetskopiering sjunker ofta kraftigt efter tiotals gigabyte när ett snabbt cacheminne fylls eller långvarigt arbete blottlägger en långsammare lagrings-, värme- eller transportbegränsning.
De första 50 GB är inte någon universell gräns. Det är en ledtråd om att överföringen har gått från burstbeteende till steady-state-beteende, nått en annan uppsättning filer, fyllt ett SSD-cacheminne, utlöst SMR-rensning, värmt upp ett kabinett eller blottlagt USB-omförsök. En korrekt diagnos jämför samma källdata genom kontrollerade tester med stora och små filer, samtidigt som mållagringens latens, temperatur, länkfel och det faktiska antalet skrivna byte registreras.
Bekräfta om hastighetsminskningen följer byte, tid eller antal filer
Upprepa en avgränsad säkerhetskopiering och registrera förfluten tid, överförda byte, antal filer, genomsnittlig filstorlek, läshastighet från källan, skrivhastighet till målet och den exakta punkt där genomströmningen sjunker.
Fio skiljer mellan sekventiella och slumpmässiga arbetsbelastningar, vilket gör det lämpligt för att fastställa om målet blir långsammare efter en viss mängd skrivna byte eller först när säkerhetskopieringen når många små filer.
Om hastighetsminskningen inträffar nära samma antal skrivna gigabyte oavsett filblandning bör du undersöka cache- och värmebegränsningar. Om den följer antalet filer eller katalogdjupet är metadata- och applikationsrelaterad overhead mer sannolik.
Kontrollera om ett SSD-cacheminne för burstskrivning har fyllts
Identifiera mållagringen och notera modell, ledigt utrymme, temperatur, inbyggd programvara och långvarigt skrivbeteende. Jämför hastigheten under den första minuten med hastigheten efter att den har sjunkit.
Crucial förklarar att SSD-prestanda kan sjunka när bakgrundens skräpsamling behöver tid för rensning, vilket är anledningen till att en kort snabb burst inte representerar enhetens långvariga skrivhastighet.
Pausa arbetsbelastningen tillräckligt länge för att enheten ska svalna och utföra bakgrundsrensning, och fortsätt sedan med samma data. En tillfällig återhämtning stöder teorin om cache- eller värmebelastning, men utan temperatur- och latensdata går det inte att avgöra vilken av dem som är orsaken.
Uteslut enhetsstyrd SMR-rensning
Kontrollera om USB-målet innehåller en enhetsstyrd SMR-disk. Jämför en stor sekventiell dataström med en säkerhetskopiering som upprepade gånger uppdaterar eller skapar många små filer.
Seagate uppger att SMR fungerar bäst med förutsägbara skrivningar, medan fragmenterade eller slumpmässiga uppdateringar kan skapa ytterligare intern dataflytt och en lägre stabil hastighet.
Dra inte slutsatsen att en enhet använder SMR enbart utifrån kapacitet eller varumärke. Bekräfta den exakta modellen och undvik att använda en enhet vars arbetsegenskaper inte passar frekventa inkrementella eller metadatatunga säkerhetskopieringar.
Kontrollera USB-återställningar, autosuspend och länkförsök
Spara värdloggarna från innan säkerhetskopieringen börjar och fram till hastighetsminskningen. Leta efter enhetsåterställningar, UAS-fel, avbrutna kommandon, ändringar av förhandlad hastighet, frånkopplingar och övergångar till autosuspend.
Linux-kärnan dokumenterar USB:s körtidsbaserade energihantering, vilket hjälper dig att skilja en lagringsmedierelaterad hastighetsminskning från en transportväg som upprepade gånger försätts i viloläge, återupptas eller återställs under långvarig belastning.
En USB-länk kan förbli ansluten samtidigt som omförsök minskar den användbara genomströmningen. Testa en direktansluten port på baksidan, en beprövad kort kabel, rätt nätadapter och en annan värd innan du ändrar filsystem- eller säkerhetskopieringsinställningar.
Fastställ om säkerhetskopieringen övergår till en arbetsbelastning med små filer
Granska säkerhetskopieringsloggen runt hastighetsminskningen och jämför genomsnittlig filstorlek, filskapandetakt, metadataoperationer, ACL-hantering, kontrollsummor, komprimering och kryptering före och efter tröskeln.
Red Hat beskriver lagring av små filer som en metadatakrävande arbetsbelastning, så ett lägre MB/s-värde kan vara normalt när säkerhetskopieringen går från stora nyttodatafiler till många skapande-, stängnings-, stat- och kataloguppdateringar.
Mät filer per sekund såväl som megabyte per sekund. En fas med små filer kan visa låg bytegenomströmning samtidigt som lagringsstacken förblir aktiv och responsiv.
Verifiera ledigt utrymme, discard och skrivförstärkning
Registrera ledigt utrymme på målet, kvarhållning av ögonblicksbilder, användning av papperskorg, tunn allokering och om discard når en SSD via USB-bryggan och filsystemet.
Handboken för fstrim förklarar att oanvända block måste kommuniceras till lagring som stöder detta innan de kan återanvändas effektivt.
Aktivera inte discard genom ett kabinett som inte vidarebefordrar det på ett säkert sätt. Skapa först ett avsiktligt utrymmesmarginal och jämför sedan samma säkerhetskopieringssegment efter en stödd rensning.
Genomför ett kontrollerat A/B-test av säkerhetskopieringen innan du byter maskinvara
Skapa en testuppsättning med stora filer och en lika stor testuppsättning med små filer. Kör båda till samma mål efter att det har svalnat och upprepa sedan testet via en annan USB-väg eller till ett annat mål, samtidigt som temperatur och fel registreras.
ZimaSpaces guide om att förbereda en stor första säkerhetskopiering beskriver en närliggande metod för att skilja schemaläggning av säkerhetskopieringar och överbelastning av nätverket från målets stabila prestanda.
Diagnosen är klar när hastighetsminskningen följer ett mätbart villkor – uttömt cacheminne, SMR-rensning, filblandning, värme, USB-omförsök eller lite återanvändbart utrymme – och den korrigerade vägen upprätthåller den förväntade stabila hastigheten.
Vanliga frågor
Bevisar en hastighetsminskning efter 50 GB att enheten har ett cacheminne på 50 GB?
Nej. Tröskeln kan också bero på förfluten tid, temperatur, filblandning, utrymmesbelastning eller intern rensning. Upprepa testet med olika datastrukturer innan du uppskattar cacheminnets storlek.
Varför återställs hastigheten tillfälligt när jag pausar säkerhetskopieringen?
Pausen kan ge en SSD möjlighet att skriva ut cachad data, en SMR-disk möjlighet att omorganisera skrivningar, ett kabinett möjlighet att svalna eller USB-transporten möjlighet att återhämta sig. Temperatur- och latensloggar behövs för att skilja orsakerna åt.
Bör jag bedöma säkerhetskopieringsprestanda utifrån den ursprungliga hastigheten?
Nej. Kapacitetsplaneringen bör utgå från den stabila hastigheten efter att cacheminnena har fyllts och arbetsbelastningen nått sin normala blandning av data, metadata, verifiering och kvarhållningsarbete.
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.
