Vad får en SSD-pool att bli långsammare när det lediga utrymmet sjunker under 15 procent?
En SSD-pool blir ofta långsammare när den närmar sig full kapacitet, eftersom styrenheten och filsystemet har mindre rent arbetsutrymme för skrivningar, omplaceringar, metadata och ögonblicksbilder.
15-procentsnivån är ingen universell gräns, men den är en användbar varningsnivå för många hemserverarbetsbelastningar. Poolen kan ha lediga logiska byte samtidigt som ögonblicksbilder, tunn provisionering, filsystemsmetadata, raderade men öppna filer eller bristande stöd för discard minskar det utrymme som SSD-styrenheter och lagringsprogram faktiskt kan återanvända. Diagnostisera det effektiva skrivbara utrymmet och skrivfördröjningen i stället för att förlita dig på en enda procentsiffra i instrumentpanelen.
Bekräfta vilket ledigt utrymme som nådde 15 procent
Jämför SSD:ns råkapacitet, poolkapacitet, filsystemets lediga utrymme, tunnprovisionerad allokering, användning av ögonblicksbilder, kvoter, reserverade block och den applikationsvolym som känns långsam. Dessa värden besvarar olika frågor.
GNU Coreutils förklarar att tillgängligt filsystemsutrymme rapporteras utifrån det monterade filsystemets redovisning, vilket kanske inte omfattar varje pool, ögonblicksbild, tunn volym eller reserv på styrenhetsnivå som påverkar skrivningar.
Om bara en datamängd eller tunn volym nästan är full ska du åtgärda det lagret i stället för att behandla alla SSD:er som långsamma. Om hela poolen har liten oallokerad kapacitet fortsätter du med kontroller av styrenhetens arbetsutrymme, discard och ögonblicksbilder.
Förstå varför NAND-skrivningar behöver rent arbetsutrymme
Mät fördröjningen för långvariga och små slumpmässiga skrivningar före och efter att poolen passerar tröskeln. Läshastigheten kan förbli acceptabel samtidigt som skrivningar pausar eller blir ojämna.
Crucial beskriver SSD-overprovisionering som reserverad kapacitet för skräpsamling, slitageutjämning och ersättningsblock. Det förklarar varför mindre skrivbart utrymme kan öka bakgrundsomflyttningen vid nya skrivningar.
Anta inte att varje avmattning innebär att flashminnet är utslitet. En felfri SSD kan tillfälligt bli långsam när den måste radera, flytta och skriva om mer giltiga data för varje ny skrivning.
Verifiera att discard eller TRIM når SSD:erna
Kontrollera om raderade filsystemblock kasseras kontinuerligt, periodiskt eller inte alls. Ta med varje lager mellan filsystemet och SSD:n: kryptering, RAID, tunn provisionering, HBA, virtuell disk och kabinett.
Microsofts retrim-åtgärd i Optimize-Volume visar att raderade block måste kommuniceras genom lagringsstacken så att enheten kan förbereda dem för återanvändning.
Ett lyckat kommando på filsystemnivå bevisar inte att SSD:n tog emot discard. Jämför enhetsräknare eller kontrollerat skrivbeteende före och efter en trimåtgärd som stöds, och aktivera inte discard genom ett lager som inte bevarar funktionen på ett säkert sätt.
Kontrollera ögonblicksbilder, papperskorgar och raderade men öppna filer
Mät utrymmet som upptas av ögonblicksbilder, kloner, kvarhållningsmappar, papperskorgar, databasloggar och öppna filer vars katalogposter har raderats. Dessa kan hålla block allokerade även efter att användarna tror att data har försvunnit.
Oracles ZFS-dokumentation förklarar att ögonblicksbilder behåller refererade block. Därför behöver radering av en stor aktiv fil inte frigöra lagringsutrymme medan äldre ögonblicksbilder fortfarande är beroende av blocken.
Radera endast kvarhållningspunkter som överskrider policyn och bekräfta vilka block de refererar till. En stor ögonblicksbild är inte automatiskt föråldrad, och en nödradering kan ta bort den enda återställningsvägen för en nylig ändring.
Skilj styrenhetens overprovisionering från filsystemets lediga utrymme
Kontrollera om varje SSD har o-partitionerat reservutrymme, ett tillverkarangivet reservområde eller värdhanterad overprovisionering. Ledigt utrymme i filsystemet och reservutrymme i styrenheten har liknande men olika funktioner.
Kingston förklarar att värdhanterad overprovisionering lämnar kapacitet oallokerad, så att SSD-styrenheten får ytterligare arbetsutrymme utöver filsystemets synliga lediga block.
Förminska inte en aktiv pool utan verifierade säkerhetskopior och en stödd metod för minskning. Overprovisionering är säkrast när den planeras före driftsättning eller införs under en kontrollerad migrering.
Kör en stödd trimåtgärd och mät återhämtningen
När du har tagit bort onödiga data och ögonblicksbilder kör du plattformens stödda discard-åtgärd under en period med låg belastning. Registrera hur många byte som kasserades och om skrivfördröjningen förändras efter att SSD:n har slutfört den bakgrundsbaserade rensningen.
Handboken för fstrim förklarar att discard gäller oanvända filsystemblock och att upprepad trimning av samma områden kanske inte ger någon ytterligare nytta.
Att en trimåtgärd rapporterar noll byte innebär inte automatiskt att den misslyckades; filsystemet kan redan vara trimmat eller så kan ett mellanliggande lager blockera discard. Använd lagringsstackens egna bevis innan du ändrar monteringsalternativ.
Återställ marginalen och verifiera den verkliga flaskhalsen
Flytta temporära data, ta endast bort ögonblicksbilder som policyn tillåter, komprimera databaser där det stöds och återställ en avsiktlig marginal av ledigt utrymme. Upprepa sedan samma skrivarbetsbelastning medan du mäter fördröjning, ködjup, CPU-väntetid och SSD-temperatur.
ZimaSpace-artikeln om varningstecken på SSD-cachefel beskriver gränsen mellan reversibelt utrymmestryck och tecken på att själva enheten kan vara på väg att gå sönder.
Diagnosen är klar när skrivfördröjningen förbättras efter verifierat ledigt utrymme eller återhämtning genom discard, ögonblicksbilder och metadata ligger inom policyn och samma arbetsbelastning förblir stabil över den valda reserven. Om prestandan fortfarande är dålig trots gott om utrymme bör du undersöka termisk strypning, slitage, styrenhetsfel, RAID-beteende eller applikationens 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.
