Was verursacht, dass ein SSD-Pool langsamer wird, wenn der freie Speicherplatz unter 15 Prozent fällt?
Ein SSD-Pool wird bei fast voller Kapazität oft langsamer, weil Controller und Dateisystem weniger sauberen Arbeitsbereich für Schreibvorgänge, Datenverschiebungen, Metadaten und Snapshots haben.
Die 15-Prozent-Marke ist kein universeller Grenzwert, aber für viele Home-Server-Workloads eine nützliche Warnschwelle. Der Pool kann zwar über freie logische Bytes verfügen, doch Snapshots, Thin Provisioning, Dateisystem-Metadaten, gelöschte, aber noch geöffnete Dateien oder fehlende Discard-Unterstützung können den tatsächlich wiederverwendbaren Speicher für SSD-Controller und Speichersoftware verringern. Ermitteln Sie den effektiv verfügbaren Schreibspielraum und die Schreiblatenz, statt sich auf einen einzigen Dashboard-Prozentwert zu verlassen.
Bestätigen Sie, welcher Wert für den freien Speicher 15 Prozent erreicht hat
Vergleichen Sie die rohe SSD-Kapazität, die Pool-Kapazität, den freien Speicherplatz des Dateisystems, die Zuweisung bei Thin Provisioning, die Snapshot-Nutzung, Kontingente, reservierte Blöcke und das Anwendungsvolume, das sich langsam anfühlt. Diese Werte beantworten unterschiedliche Fragen.
GNU Coreutils erklärt, dass der verfügbare Speicherplatz des Dateisystems anhand der Kontoführung des eingebundenen Dateisystems gemeldet wird. Diese muss nicht jeden Pool, Snapshot, jedes Thin-Volume oder jede auf Controller-Ebene reservierte Kapazität berücksichtigen, die Schreibvorgänge beeinflusst.
Wenn nur ein Dataset oder Thin-Volume fast voll ist, beheben Sie das Problem auf dieser Ebene, statt jede SSD als langsam einzustufen. Wenn im gesamten Pool nur wenig nicht zugewiesene Kapazität vorhanden ist, fahren Sie mit der Prüfung des Controller-Arbeitsbereichs, von Discard und Snapshots fort.
Verstehen Sie, warum NAND-Schreibvorgänge sauberen Arbeitsbereich benötigen
Messen Sie die Latenz bei sequenziellen und kleinen zufälligen Schreibvorgängen, bevor und nachdem der Pool den Schwellenwert unterschreitet. Die Lesegeschwindigkeit kann akzeptabel bleiben, während Schreibvorgänge pausieren oder ungleichmäßig werden.
Crucial beschreibt das Over-Provisioning von SSDs als reservierte Kapazität für Garbage Collection, Wear-Leveling und Ersatzblöcke. Das erklärt, warum weniger verfügbarer Schreibspielraum bei neuen Schreibvorgängen zu mehr Hintergrundverschiebungen führen kann.
Gehen Sie nicht davon aus, dass jede Verlangsamung auf abgenutzten Flash-Speicher hindeutet. Auch eine intakte SSD kann vorübergehend langsam werden, wenn sie für jeden eingehenden Schreibvorgang mehr gültige Daten löschen, verschieben und neu schreiben muss.
Überprüfen Sie, ob Discard oder TRIM die SSDs erreicht
Prüfen Sie, ob gelöschte Dateisystemblöcke kontinuierlich, regelmäßig oder überhaupt nicht verworfen werden. Beziehen Sie jede Ebene zwischen Dateisystem und SSD ein: Verschlüsselung, RAID, Thin Provisioning, HBA, virtuelle Festplatte und Gehäuse.
Die Retrim-Operation von Microsofts Optimize-Volume zeigt, dass gelöschte Blöcke durch den Speicher-Stack weitergegeben werden müssen, damit das Gerät sie für die Wiederverwendung vorbereiten kann.
Ein erfolgreicher Befehl auf Dateisystemebene beweist nicht, dass die SSD Discard erhalten hat. Vergleichen Sie Gerätezähler oder das kontrollierte Schreibverhalten vor und nach einem unterstützten TRIM-Vorgang. Aktivieren Sie Discard nicht über eine Ebene, die es nicht sicher weiterreicht.
Prüfen Sie Snapshots, Papierkörbe und gelöschte, aber noch geöffnete Dateien
Messen Sie den von Snapshots, Klonen, Aufbewahrungsordnern, Papierkörben, Datenbankprotokollen und geöffneten Dateien belegten Speicher, deren Verzeichniseinträge gelöscht wurden. Diese können Blöcke weiterhin zugewiesen halten, obwohl Benutzer davon ausgehen, dass die Daten entfernt wurden.
Die ZFS-Dokumentation von Oracle erklärt, dass Snapshots referenzierte Blöcke beibehalten. Daher gibt das Löschen einer großen aktiven Datei ihren Speicherplatz möglicherweise nicht frei, solange ältere Snapshots weiterhin von diesen Blöcken abhängen.
Löschen Sie nur Aufbewahrungspunkte, die über die Richtlinien hinausgehen, und bestätigen Sie, auf welche Blöcke sie verweisen. Ein großer Snapshot ist nicht automatisch veraltet, und ein Löschen im Notfall kann den einzigen Wiederherstellungspfad für eine kürzlich vorgenommene Änderung entfernen.
Trennen Sie Controller-Over-Provisioning vom freien Speicherplatz des Dateisystems
Prüfen Sie, ob jede SSD über nicht partitionierten Reserveplatz, einen vom Hersteller definierten Ersatzbereich oder hostverwaltetes Over-Provisioning verfügt. Freier Speicherplatz im Dateisystem und Controller-Reserve erfüllen verwandte, aber unterschiedliche Zwecke.
Kingston erklärt, dass hostseitiges Over-Provisioning Kapazität nicht zuweist, damit der SSD-Controller über zusätzlichen Arbeitsbereich jenseits der für das Dateisystem sichtbaren freien Blöcke verfügt.
Verkleinern Sie einen aktiven Pool nicht ohne verifizierte Backups und einen unterstützten Weg zur Verkleinerung. Over-Provisioning ist am sichersten, wenn es vor der Bereitstellung geplant oder im Rahmen einer kontrollierten Migration eingeführt wird.
Führen Sie einen unterstützten TRIM-Vorgang aus und messen Sie die Erholung
Entfernen Sie unnötige Daten und Snapshots und führen Sie anschließend in einem Zeitraum mit geringer Auslastung den unterstützten Discard-Vorgang der Plattform aus. Notieren Sie, wie viele Bytes verworfen wurden und ob sich die Schreiblatenz verändert, nachdem die SSD die Hintergrundbereinigung abgeschlossen hat.
Das fstrim-Handbuch erklärt, dass Discard auf ungenutzte Dateisystemblöcke angewendet wird und wiederholtes Trimmen derselben Bereiche möglicherweise keinen zusätzlichen Nutzen bringt.
Ein TRIM-Vorgang, der null Bytes meldet, ist nicht automatisch fehlgeschlagen. Das Dateisystem wurde möglicherweise bereits getrimmt, oder eine Zwischenschicht blockiert Discard. Nutzen Sie die eigenen Nachweise des Speicher-Stacks, bevor Sie Einhängeoptionen ändern.
Stellen Sie den freien Spielraum wieder her und überprüfen Sie den tatsächlichen Engpass
Verschieben Sie temporäre Daten, lassen Sie nur richtlinienkonforme Snapshots ablaufen, komprimieren Sie Datenbanken, sofern dies unterstützt wird, und stellen Sie einen bewusst geplanten Freispeicherpuffer wieder her. Wiederholen Sie anschließend denselben Schreib-Workload und messen Sie Latenz, Warteschlangentiefe, CPU-Wartezeit und SSD-Temperatur.
Der ZimaSpace-Artikel über Warnzeichen für einen SSD-Cache-Ausfall beschreibt die angrenzende Abgrenzung zwischen reversiblem Speicherdruck und Anzeichen dafür, dass das Gerät selbst ausfallen könnte.
Die Diagnose ist abgeschlossen, wenn sich die Schreiblatenz nach verifiziertem zusätzlichem Speicherplatz oder der Wiederherstellung von Discard verbessert, Snapshots und Metadaten innerhalb der Richtlinien bleiben und derselbe Workload oberhalb der gewählten Reserve stabil bleibt. Bleibt die Leistung trotz ausreichend Speicherplatz schlecht, untersuchen Sie thermische Drosselung, Verschleiß, Controllerfehler, RAID-Verhalten oder die I/O-Aktivität der Anwendung.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Kann Plex eine GPU mit einem anderen Docker-Container gemeinsam nutzen?
Plex und ein weiterer Container können häufig auf dieselbe GPU zugreifen, aber du musst die Treiberunterstützung, die Gerätezuordnung, die Auslastung der Video-Engine, den Speicher...
So erkennst du, ob ein Plex-Fehler vom Client oder vom Server verursacht wird
Reproduziere dasselbe Element auf einem anderen Client, vergleiche den Sitzungspfad und sammle Serverbelege erst, nachdem der Geltungsbereich dir gezeigt hat, wo der Fehler tatsächlich...
So konfigurierst du den Plex-Cache und den temporären Transcodierungs-Speicher
Schütze den persistenten Plex-Zustand, indem du temporäre Transcodierungsdateien auf geeignetem lokalem Speicher ablegst, und überprüfe anschließend die Bereinigung, den freien Speicherplatz und das Verhalten...
