SMB-kopieringshastighet sjunker med tusentals små filer: Vad bör du testa först?
Testa om det är antalet filer, inte länkhastigheten, som är orsaken innan du ändrar SMB- eller nätverksinställningar.
På en hemmabaserad NAS tvingar tusentals små filer klienten och servern att upprepa sökvägsuppslagning, behörighetskontroller, öppningar, skapanden, metadatauppdateringar, stängningar och applikationssidesökning för varje objekt. En gigabit- eller 2,5GbE-länk kan förbli mestadels inaktiv medan kopieringen ändå kryper fram, så det första användbara steget är ett A/B-test som håller totala byteantalet liknande men ändrar objektsantalet, följt av tester av lagring, klient och kopieringsverktyg i en fast ordning.
Jämför en stor fil med samma antal byte i små filer
Skapa två testuppsättningar på samma käll-lagring: en stor fil och en mapp som innehåller tusentals små filer med ungefär samma totala storlek. Kopiera båda till samma NAS-delning med samma klient, SMB-sökväg och tidsfönster.
En TrueNAS-användarrapport visar det karakteristiska mönstret av SMB-försening vid små filer medan stora filer höll nästan normal nätverkshastighet. Den kontrasten är mer användbar än en enda hastighetssiffra eftersom den bevisar att arbetsbelastningens form ändrar flaskhalsen.
Registrera förfluten tid, totala filer, totala byte, filer per sekund, genomsnittlig MB/s och om förseningen börjar omedelbart eller först efter att en cache fyllts. Om båda uppsättningarna är långsamma, undersök först det allmänna nätverket eller lagringsvägen; om endast småfiluppsättningen kollapsar, fortsätt med metadatafokuserade tester.
Separera nätverkskapacitet från arbete per fil
Kör ett minne-till-minne-nätverkstest mellan samma klient och NAS, och jämför sedan med resultatet för stora filer via SMB. Ett rent nätverkstest och en snabb kopiering av stora filer visar att länken kan bära data även om arbetsbelastningen med små filer inte kan hålla den full.
Små filer omvandlar kopieringen till upprepat begäran-och-svar-arbete. Eclectic Light dokumenterade hur SMB-säkerhetskopieringar med mycket metadata kan ta oväntat lång tid även när lite nyttolastdata flyttas.
Ändra inte MTU, duplex eller länkaggregering som första åtgärd efter det resultatet. Följ istället filer per sekund och belastad latens; nästa användbara fråga är om det upprepade arbetet väntar på källan, NAS-destinationen eller klientens inspektion.
Testa metadata-latens för källa och destination separat
Kopiera småfiluppsättningen från källan till en annan lokal mapp på klienten, och skapa eller extrahera sedan samma uppsättning lokalt på NAS. Dessa två tester isolerar käll-läsningar och NAS-skapanden utan att SMB är inblandat.
En direkt diskussion på Unraid mätte långsamma operationer per fil som inte var synliga vid överföringar av stora filer. Den viktiga signalen är om lokal destinationsskapning redan är långsam innan nätverket är involverat.
Om klient-lokal kopiering är långsam, undersök källdisken, filsystemet, kryptering och filstruktur. Om NAS-lokal skapning är långsam, undersök destinationspoolen, cache-lagret, paritetsvägen, fragmentering av ledigt utrymme, metadataenheten och synkront skrivbeteende innan du justerar SMB.
Mät säkerhetsskanning och indexering på båda ändpunkterna
Antivirus, endpoint-skydd, miniatyrgenerering, innehållsindexering, synkroniseringsövervakare och mediascanners kan inspektera varje ny fil. Deras fasta kostnad per objekt kan dominera en arbetsbelastning som snabbt skapar tusentals objekt.
Kör ett kontrollerat test där realtidsskanning och indexering tillfälligt utesluts endast för den dedikerade testmappen, och återställ sedan skyddet omedelbart. Syftet är inte att lämna säkerheten avstängd, utan att avgöra om förseningen följer per-fil-inspektion.
Om filer per sekund ökar kraftigt, skapa en säkrare långsiktig uteslutning endast för betrodd backup-staging eller genererade cachedata, eller schemalägg skanningen efter överföringen. Om resultatet inte ändras, återställ de ursprungliga inställningarna och gå vidare till kopieringsverktygets beteende istället för att samla på oförklarade undantag.
Jämför kopieringsverktyg och samtidighet utan att ändra datasetet
File Explorer, Finder, Robocopy, rsync, backup-klienter och arkiveringsverktyg kan använda olika ködjup, metadataanrop, återförsöksregler och parallellism. Jämför två verktyg mot samma källträd och destination istället för att jämföra orelaterade arbetsbelastningar.
Resilios diskussion om skanning av stora filantal illustrerar varför ett jobb kan förbli metadata-bundet även när lite innehåll ändras. Fler trådar kan dölja viss latens, men de kan också överbelasta NAS med samtidiga skapanden.
Öka samtidigheten stegvis och stoppa när filer per sekund slutar förbättras, latensen stiger kraftigt eller NAS börjar köa skrivningar. Behåll inställningen som konsekvent förbättrar den verkliga arbetsbelastningen, inte det högsta värdet verktyget tillåter.
Använd resultatmönstret för att välja den minsta åtgärden
Diagnosen bör peka på ett dominerande steg: nätverkskapacitet, käll-läsningar, NAS-skapanden, ändpunktsskanning, SMB-begärandebeteende eller kopieringsverktyget. Kombinera inte alla möjliga justeringar i ett experiment eftersom den slutliga hastighetsförändringen då inte längre förklarar orsaken.
ZimaSpaces förklaring av hur filantal ökar NAS-arbetet ger den underliggande anledningen till att filer per sekund kan vara viktigare än MB/s för denna arbetsbelastning.
Acceptera åtgärden endast när samma småfiluppsättning förbättras över upprepade körningar utan att skada hastigheten för stora filer, behörigheter, återställningsbeteende eller NAS-respons. När individuell återställning inte är nödvändig kan paketering av oföränderliga små filer i ett arkiv minska objektsöverhead, men det är ett arbetsflödesbeslut snarare än en universell SMB-reparation.
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.
