Cosa fa rallentare un pool SSD quando lo spazio libero scende sotto il 15%?
Un pool SSD spesso rallenta quando si avvicina alla capacità massima perché il controller e il filesystem hanno meno spazio di lavoro libero per le scritture, la riallocazione, i metadati e gli snapshot.
La soglia del 15% non rappresenta un limite universale, ma è un utile campanello d’allarme per molti carichi di lavoro su home server. Il pool può avere byte logici liberi, mentre snapshot, thin provisioning, metadati del filesystem, file eliminati ma ancora aperti o il mancato supporto al discard riducono lo spazio che i controller SSD e il software di storage possono effettivamente riutilizzare. Diagnostica lo spazio scrivibile effettivo e la latenza di scrittura invece di affidarti a un’unica percentuale nella dashboard.
Conferma quale valore di spazio libero ha raggiunto il 15%
Confronta la capacità grezza degli SSD, la capacità del pool, lo spazio libero del filesystem, l’allocazione con thin provisioning, l’utilizzo degli snapshot, le quote, i blocchi riservati e il volume applicativo che sembra lento. Questi valori rispondono a domande diverse.
GNU Coreutils spiega che lo spazio disponibile del filesystem viene calcolato in base alla contabilità del filesystem montato, che potrebbe non includere ogni riserva del pool, degli snapshot, dei volumi thin o del controller che influisce sulle scritture.
Se solo un dataset o un volume thin è quasi pieno, intervieni su quel livello invece di considerare l’intero SSD lento. Se l’intero pool ha poca capacità non allocata, continua con i controlli sullo spazio di lavoro del controller, sul discard e sugli snapshot.
Comprendi perché le scritture NAND hanno bisogno di spazio di lavoro libero
Misura la latenza delle scritture sostenute e casuali di piccole dimensioni prima e dopo che il pool supera la soglia. La velocità di lettura può rimanere accettabile mentre le scritture subiscono pause o diventano incostanti.
Crucial descrive l’over-provisioning degli SSD come una capacità riservata per la garbage collection, il wear leveling e i blocchi sostitutivi; ciò spiega perché una minore disponibilità di spazio scrivibile possa aumentare la riallocazione in background durante le nuove scritture.
Non dare per scontato che ogni rallentamento significhi memoria flash usurata. Un SSD integro può diventare temporaneamente lento quando deve cancellare, spostare e riscrivere una quantità maggiore di dati validi per ogni nuova scrittura.
Verifica che il discard o il TRIM raggiunga gli SSD
Controlla se i blocchi eliminati dal filesystem vengono scartati continuamente, periodicamente oppure mai. Includi ogni livello tra filesystem e SSD: crittografia, RAID, thin provisioning, HBA, disco virtuale e enclosure.
L’operazione retrim di Optimize-Volume di Microsoft mostra che i blocchi eliminati devono essere comunicati attraverso lo stack di storage affinché il dispositivo possa prepararli per il riutilizzo.
Un comando eseguito correttamente a livello di filesystem non dimostra che l’SSD abbia ricevuto il discard. Confronta i contatori del dispositivo o il comportamento di scrittura controllato prima e dopo un’operazione TRIM supportata, e non abilitare il discard attraverso un livello che non lo gestisce in modo sicuro.
Controlla snapshot, cestini e file eliminati ma ancora aperti
Misura lo spazio occupato da snapshot, cloni, cartelle di conservazione, cestini, log dei database e file aperti le cui voci di directory sono state eliminate. Questi elementi possono mantenere allocati i blocchi anche quando gli utenti credono che i dati siano stati rimossi.
La documentazione ZFS di Oracle spiega che gli snapshot conservano i blocchi referenziati; pertanto, l’eliminazione di un file attivo di grandi dimensioni potrebbe non restituire spazio finché gli snapshot più vecchi dipendono ancora da quei blocchi.
Elimina solo i punti di conservazione che superano i criteri previsti e verifica quali blocchi referenziano. Uno snapshot di grandi dimensioni non è automaticamente obsoleto, e una cancellazione d’emergenza può rimuovere l’unico percorso di ripristino per una modifica recente.
Separa l’over-provisioning del controller dallo spazio libero del filesystem
Controlla se ogni SSD dispone di spazio riservato non partizionato, di un’area spare definita dal produttore o di over-provisioning gestito dall’host. Lo spazio libero del filesystem e la riserva del controller hanno funzioni correlate, ma diverse.
Kingston spiega che l’over-provisioning dell’host lascia una parte della capacità non allocata, così il controller SSD dispone di spazio di lavoro aggiuntivo oltre ai blocchi liberi visibili dal filesystem.
Non ridurre un pool attivo senza backup verificati e un percorso di riduzione supportato. L’over-provisioning è più sicuro se pianificato prima della distribuzione o introdotto durante una migrazione controllata.
Esegui un TRIM supportato e misura il recupero
Dopo aver rimosso dati e snapshot non necessari, esegui l’operazione di discard supportata dalla piattaforma durante una finestra di basso carico. Registra quanti byte sono stati scartati e se la latenza di scrittura cambia dopo che l’SSD completa la pulizia in background.
Il manuale di fstrim spiega che il discard si applica ai blocchi inutilizzati del filesystem e che il trimming ripetuto delle stesse aree potrebbe non offrire ulteriori vantaggi.
Un’operazione TRIM che segnala zero byte non indica automaticamente un errore: il filesystem potrebbe essere già stato sottoposto a TRIM oppure un livello intermedio potrebbe bloccare il discard. Usa le informazioni fornite dallo stack di storage prima di modificare le opzioni di montaggio.
Ripristina spazio libero e verifica il vero collo di bottiglia
Sposta i dati temporanei, elimina solo gli snapshot approvati dai criteri di conservazione, compatta i database quando supportato e ripristina un margine deliberato di spazio libero. Poi ripeti lo stesso carico di scrittura misurando latenza, profondità della coda, attesa della CPU e temperatura degli SSD.
L’articolo di ZimaSpace sui segnali di allarme della cache SSD offre il contesto per distinguere la pressione reversibile dovuta allo spazio ridotto dalle prove che il dispositivo potrebbe essere guasto.
La diagnosi è completa quando la latenza di scrittura migliora dopo aver verificato il recupero di spazio libero o del discard, gli snapshot e i metadati rimangono entro i criteri stabiliti e lo stesso carico resta stabile al di sopra della riserva scelta. Se le prestazioni rimangono scarse nonostante lo spazio disponibile, indaga il throttling termico, l’usura, gli errori del controller, il comportamento del RAID o l’I/O dell’applicazione.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
