Så tar du reda på om SMB-tröghet beror på signering eller lagring

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How to Tell Whether SMB Slowness Comes From Signing or Storage - Zima Store Online

Jämför signerade och osignerade testvägar först efter att ha mätt lokala disk- och råa nätverksbegränsningar; signering är inte den vanliga boven.

Beslutet är viktigt när ett betrott LAN når lägre SMB-genomströmning än förväntat på en strömsnål NAS. De två konkurrerande tillstånden är CPU-kostnaden för signering eller kryptering samt begränsningar i disk, metadata, nätverk eller enskilda strömmar. Börja med en sparad konfiguration och data som kan raderas, observera en gren i taget och avbryt om testet ökar risken för dataförlust, behörighetsproblem eller otillgänglighet.

Separera CPU-kostnaden för signering eller kryptering från begränsningar i disk, metadata, nätverk eller enskilda strömmar

Dokumentera miljön innan du ändrar något: program- och firmwareversioner, enhetsidentiteter, monterings- eller nätverkssökväg, ledigt utrymme, behörigheter och det observerbara symptomet. Baslinjen måste innehålla tillräckligt med detaljer för att återskapa att ett betrott LAN når lägre SMB-genomströmning än förväntat på en strömsnål NAS.

Den första kandidaten är CPU-kostnaden för signering eller kryptering. Den andra är begränsningar i disk, metadata, nätverk eller enskilda strömmar. Den aktuella SMB-signeringsfunktionen definierar den mekanism eller kommandogräns som används i testet; den ersätter inte observationer från just den här hemservern.

Skriv ned godkännandekriteriet och stoppkriteriet innan du kör särskiljningstestet. Ett godkänt resultat måste ändra de belägg som förutsägs av en gren samtidigt som orelaterade tjänster förblir oförändrade; ett misslyckat resultat måste återställa systemet till det sparade tillståndet i stället för att utlösa en kedja av spekulativa åtgärder.

Kör ett kontrollerat särskiljningstest

Använd följande särskiljningstest: mät lokal sekventiell lagring och lagring med små filer, iperf, förhandlad SMB-säkerhet och CPU, och upprepa sedan en kontrollerad SMB-överföring. Håll arbetsbelastning, klient, sökväg, filuppsättning och tidsinställning konstanta så att resultatet kan kopplas till den ändrade variabeln.

Använd Samba-inställningarna för signering för att välja det fält som faktiskt kan skilja grenarna åt, och registrera sedan dess tidsstämpel, avslutningsstatus, feltext, enhets- eller ögonblicksbildsidentitet, latens, överförda byte, behörigheter och återställningstillstånd. Ett felfritt kommandoavslut räcker inte när identitet, beständighet eller programtillstånd är det som testas.

Upprepa testet en gång efter en omstart, återanslutning, ommontering eller tom cache när den händelsen ingår i det ursprungliga tillståndet. Om den första körningen är destruktiv eller miljön inte kan återställas ska du avbryta och i stället återskapa problemet på en kopia som kan raderas.

Get-SmbConnection | Select ServerName,Dialect,Signed
# Jämför med NAS-CPU, disklatens och iperf

Tolka vilken gren beläggen stöder

GODKÄNT: CPU:n blir mättad endast med signering medan disk och nätverk har kapacitet kvar, eller så förblir lagringslatensen hög oavsett signering. Dokumentera den exakta versionen, identiteten och arbetsbelastningen som gav godkänt resultat så att slutsatsen förblir villkorad i stället för att bli ett universellt påstående.

UNDERKÄNT: prestandan följer filstorlek, diskkö, Wi-Fi eller nätverkssökväg snarare än säkerhetstillståndet. Ett underkänt resultat bevisar inte automatiskt den motsatta grenen när nätverk, minne, behörigheter eller källans konsekvens kan påverka båda; isolera dessa gemensamma beroenden innan du eskalerar.

UNDANTAG ELLER TVETYDIGT RESULTAT: återställ obligatorisk signering och optimera det bekräftade lägre lagret innan du accepterar svagare integritet. Spara loggarna och kör inte reparations-, rensnings-, förstörings-, ompartitionerings- eller rekursiva ägarändringskommandon förrän en återställningsbar kopia finns.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Tillämpa den matchande åtgärden och återskapa det ursprungliga felet

Tillämpa åtgärden som matchar den observerade grenen och upprepa sedan det ursprungliga tillståndet i stället för en förenklad ersättning. Beslutet gäller endast när CPU:n blir mättad endast med signering medan disk och nätverk har kapacitet kvar, eller när lagringslatensen förblir hög oavsett signering, under två cykler eller den relevanta omstarten, viloläget, avbrottet eller belastningsövergången.

Använd beständiga SMB-handtag för att kontrollera det närmast beroende arbetsflödet, men behåll den ursprungliga utlösaren oförändrad. Orelaterade datauppsättningar, utdelningar, containrar, användare och återställningspunkter måste behålla sin tidigare åtkomst och tidsåtgång.

Stoppgränsen är tydlig: om prestandan följer filstorlek, diskkö, Wi-Fi eller nätverkssökväg snarare än säkerhetstillståndet ska du återgå till den senast verifierade konfigurationen, behålla beläggen och endast eskalera till ett djupare plattforms- eller hårdvarutest när grenen kan upprepas.

När målresultatet kvarstår ska du jämföra det med Wi-Fi-överföringstesterna så att åtgärden inte flyttar risken till en närliggande tjänst. Ett lyckat måltest med ett nytt fel i säkerhetskopiering, identitet, timeout eller tillgänglighet är fortfarande en misslyckad ändring.

Vanliga frågor

För SMB-signering jämfört med lagringsflaskhalsar gäller de återstående sökningarna vanligtvis om signering bör inaktiveras för ett riktmärke, varför små filer är långsammare än en stor fil och om flerkanalsteknik kan dölja en signeringsflaskhals. Svaren nedan håller dessa specialfall åtskilda från huvudbeslutet.

Godkännandegränsen ändras inte: CPU:n blir mättad endast med signering medan disk och nätverk har kapacitet kvar, eller så förblir lagringslatensen hög oavsett signering. Om ett uppföljande villkor ändrar filsystem, identitet, nätverkssökväg eller programversion ska du bara upprepa det särskiljningstest som påverkas av ändringen.

Sluta bredda experimentet när prestandan följer filstorlek, diskkö, Wi-Fi eller nätverkssökväg snarare än säkerhetstillståndet. Då ska du återställa obligatorisk signering och optimera det bekräftade lägre lagret innan du accepterar svagare integritet; spara beläggen innan du eskalerar till plattforms-, lagrings- eller hårdvaruansvarig.

Bör signering inaktiveras för ett riktmärke?

Endast på en isolerad, betrodd testväg och endast om policyn tillåter det; återställ den omedelbart efteråt.

Varför är små filer långsammare än en stor fil?

Metadataresor och lagringslatens dominerar, så signering kan utgöra endast en liten del av den totala tiden.

Kan flerkanalsteknik dölja en signeringsflaskhals?

Den kan fördela arbetet över anslutningar och CPU-kärnor, men verifiera den förhandlade säkerheten och serverns faktiska begränsningar.

Diagnosen är klar när samma arbetsbelastning får beläggen att följa CPU-kostnaden för signering eller kryptering, eller begränsningar i disk, metadata, nätverk eller enskilda strömmar, och den matchande åtgärden tar bort det ursprungliga symptomet utan att skapa ett nytt. Om ingen av grenarna förblir reproducerbar ska du behålla loggarna och det sparade tillståndet intakta; osäkerhet är ett skäl att eskalera, inte att stapla fler åtgärder.