9
Samsung QVO nutzt SLC-Cache nicht mehr
Hallo,
wir haben in der Firma 8TB Samsung QVO-SSDs in einem Ceph-Cluster genutzt. Grund, wir benötigten ein Datengrab und die Server haben nur 2,5'' Einschübe. Das man per Ceph dann keine Performance-Wunder erwarten kann, ist klar.
Ich weiß das da der interne Cache der SSDs abgeschaltet wird. Leider passierte es aber das nach ein paar Wochen in diesem Pool die Schreirate auf 20MB/Sek eingebrochen ist. Das es an diesen 8TB-SSDs lag sah man mit iotop das bei diesen Platten immer nahe 100% anzeigte. Das seltsame ist das die 4TB QVO SSDs die sich in dem gleichen Pool befinden dieses Problem nicht haben. Nebenbei bemerkt hingen alle SSDs an Raidcontrollern die kein Discard/Trim unterstützen.
Diese 8TB SSDs habe ich dann aus dem Pool entfernt um die lokal an einem Server weiternutzen zu wollen der keinen Raidcontroller besitzt. Die SSDs wurden also an den Chipsatz angeschlossen und Trim/Discard Befehle kommen durch. Ich bin jetzt davon ausgegangen das ich die SSDs damit wieder refreshen kann. Die Schreibrate bei zwei der drei SSDs lag aber trotzdem nur bei ca 160MB/sec. Es sollte nach dem trimmen aber 500MB/sec sein. Bei einer der SSDs erreichte ich auch 500MB/sec, aber nach 75GB brach sie ein und lässt sich auch nicht wieder reaktivieren, schreibt also auch nur mit ca 160MB/sec. Das deutet darauf hin das der SLC-Cache voll ist. Ich habe schon alle möglichen Discards ausprobiert. Mit Partition/ext4, fstrim angewendet, das ganze auch ohne Partition, sondern direkt das FS auf die Platte. Nix, nur maximal 160MB/sec. Reset über hdparm wird abgewiesen. Brachte also auch nichts.
Hat jemand noch eine Idee?
Vielen Dank schon mal
Nachtrag: SMART-Werte sind ok. Es werden nur 2-4% Wearout bei diesen SSDs angezeigt
wir haben in der Firma 8TB Samsung QVO-SSDs in einem Ceph-Cluster genutzt. Grund, wir benötigten ein Datengrab und die Server haben nur 2,5'' Einschübe. Das man per Ceph dann keine Performance-Wunder erwarten kann, ist klar.
Ich weiß das da der interne Cache der SSDs abgeschaltet wird. Leider passierte es aber das nach ein paar Wochen in diesem Pool die Schreirate auf 20MB/Sek eingebrochen ist. Das es an diesen 8TB-SSDs lag sah man mit iotop das bei diesen Platten immer nahe 100% anzeigte. Das seltsame ist das die 4TB QVO SSDs die sich in dem gleichen Pool befinden dieses Problem nicht haben. Nebenbei bemerkt hingen alle SSDs an Raidcontrollern die kein Discard/Trim unterstützen.
Diese 8TB SSDs habe ich dann aus dem Pool entfernt um die lokal an einem Server weiternutzen zu wollen der keinen Raidcontroller besitzt. Die SSDs wurden also an den Chipsatz angeschlossen und Trim/Discard Befehle kommen durch. Ich bin jetzt davon ausgegangen das ich die SSDs damit wieder refreshen kann. Die Schreibrate bei zwei der drei SSDs lag aber trotzdem nur bei ca 160MB/sec. Es sollte nach dem trimmen aber 500MB/sec sein. Bei einer der SSDs erreichte ich auch 500MB/sec, aber nach 75GB brach sie ein und lässt sich auch nicht wieder reaktivieren, schreibt also auch nur mit ca 160MB/sec. Das deutet darauf hin das der SLC-Cache voll ist. Ich habe schon alle möglichen Discards ausprobiert. Mit Partition/ext4, fstrim angewendet, das ganze auch ohne Partition, sondern direkt das FS auf die Platte. Nix, nur maximal 160MB/sec. Reset über hdparm wird abgewiesen. Brachte also auch nichts.
Hat jemand noch eine Idee?
Vielen Dank schon mal
Nachtrag: SMART-Werte sind ok. Es werden nur 2-4% Wearout bei diesen SSDs angezeigt
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667189
Url: https://administrator.de/forum/samsung-qvo-nutzt-slc-cache-nicht-mehr-667189.html
Ausgedruckt am: 02.02.2025 um 11:02 Uhr
9 Kommentare
Neuester Kommentar
Sers,
läuft das (OSD) Journal auch auf den QVOs?
Grüße,
Philip
läuft das (OSD) Journal auch auf den QVOs?
Grüße,
Philip
Ja, bei den 4TBs auch jetzt noch, aber ich hatte es bevor ich die 8TBs aus dem Ceph entfernt hatte auch mal auf jeweils eine andere 1TB SSD die nicht so das Problem hatte ausgelagert gehabt. Es wurde besser, aber es war nicht ideal. Daher dachte ich das ich die einfach als lokale SSDs an einem Server ohne Raidcontroller besser nutzen kann.
Aber wie gesagt, das Hauptproblem ist nicht das Ceph, sondern das sich die SSDs nicht mehr wie (fast) neue SSDs anfühlen.
Aber wie gesagt, das Hauptproblem ist nicht das Ceph, sondern das sich die SSDs nicht mehr wie (fast) neue SSDs anfühlen.
QLC SSDs sind per se nicht auf Writes ausgelegt, auch dann nicht, wenn sie einen "SLC Cache" Anteil mitbringen.
Das Journal puffert alle Writes bevor sie auf das OSD selbst geschrieben werden. Bedeutet, wenn Journal und OSD auf demselben Datenträger liegen, was zu einer Write Amplification führt. Sprich, mehrere echte Writes je logischen Write.
Lager das Journal lieber auf eine Write optimierte SSD aus, oder zumindest einer für mixed use. Dabei bitte die Abhängigkeiten zwischen OSD und Journal nicht vergessen!
Hast du dir die Hardware Recommendations schon durchgelesen?
Die 75GB sehen nach "SLC Cache voll" aus. Firmware aktuell? Das Verschieben der Daten vom SLC in den QLC Bereich sollte die SSD von selbst erledigen.
:edit: Allgemein scheint die Performance der 8TB Version der "870 QVO" problematisch zu sein: https://www.storagereview.com/review/samsung-870-qvo-sata-ssd-review-8tb
Das Journal puffert alle Writes bevor sie auf das OSD selbst geschrieben werden. Bedeutet, wenn Journal und OSD auf demselben Datenträger liegen, was zu einer Write Amplification führt. Sprich, mehrere echte Writes je logischen Write.
Lager das Journal lieber auf eine Write optimierte SSD aus, oder zumindest einer für mixed use. Dabei bitte die Abhängigkeiten zwischen OSD und Journal nicht vergessen!
Hast du dir die Hardware Recommendations schon durchgelesen?
Die 75GB sehen nach "SLC Cache voll" aus. Firmware aktuell? Das Verschieben der Daten vom SLC in den QLC Bereich sollte die SSD von selbst erledigen.
:edit: Allgemein scheint die Performance der 8TB Version der "870 QVO" problematisch zu sein: https://www.storagereview.com/review/samsung-870-qvo-sata-ssd-review-8tb
Das mit dem Ceph ist mir schon klar. Wir nutzen ja auch die PM-Serie von Samsung für Daten mit denen gearbeitet wird. So wie der jetzt läuft ist auch alles erwartungsgemäß.
Diese 8TBs sind aber schon seit Tagen leer mit discard Option gemoutet und bessern sich aber nicht. So als ob die keine Lust haben den SLC-Cache frei zu räumen. Firmware ist tatsächlich nicht die Aktuelle, wobei ich aber keine History finde was verbessert wurde.
Diese 8TBs sind aber schon seit Tagen leer mit discard Option gemoutet und bessern sich aber nicht. So als ob die keine Lust haben den SLC-Cache frei zu räumen. Firmware ist tatsächlich nicht die Aktuelle, wobei ich aber keine History finde was verbessert wurde.
Hallo zusammen,
gab es hier Erkenntnisse zu den QVOs? Ich habe exakt das selbe Problem. In unserem Cluster waren auch einige QVOs welche nach knapp 2 Jahren mit erhöhten Latenzen aufgefallen sind. Der Cluster besteht sonnst nur aus günstigen TLC SSDs welche seit 6 Jahren klaglos laufen. Die QVOs habe ich rausgeholt und entsprechend getestet. Ich bekomme lesend auch nur max. 160mb/s, schreibend viel weniger. Ein blkdiscard hat keine Veränderung gebracht. SMART Werte sind auch i.O. Wearout und TBW waren bei nichtmal 10% Abnutzung.
Meine Vermutung ist, dass der schnellere SLC oder TLC Cache durch die Nutzung im CEPH totgeschrieben wurde und nun kaum noch nutzbar ist.
Ich versuche noch einmal die Samsung Tools zu verwenden, bin aber gern für andere Ratschläge offen. Ich möchte ungern 1000€ versenken.
Gruß, Christian
gab es hier Erkenntnisse zu den QVOs? Ich habe exakt das selbe Problem. In unserem Cluster waren auch einige QVOs welche nach knapp 2 Jahren mit erhöhten Latenzen aufgefallen sind. Der Cluster besteht sonnst nur aus günstigen TLC SSDs welche seit 6 Jahren klaglos laufen. Die QVOs habe ich rausgeholt und entsprechend getestet. Ich bekomme lesend auch nur max. 160mb/s, schreibend viel weniger. Ein blkdiscard hat keine Veränderung gebracht. SMART Werte sind auch i.O. Wearout und TBW waren bei nichtmal 10% Abnutzung.
Meine Vermutung ist, dass der schnellere SLC oder TLC Cache durch die Nutzung im CEPH totgeschrieben wurde und nun kaum noch nutzbar ist.
Ich versuche noch einmal die Samsung Tools zu verwenden, bin aber gern für andere Ratschläge offen. Ich möchte ungern 1000€ versenken.
Gruß, Christian
Kurze Rückmeldung, für andere Betroffene.
nach Durchführung eines "bkldiscard /dev/sdx" im Linux hatte sich ja keine unmittelbare Änderung gezeigt. Das sieht nun nach 2 Tagen anders aus. Leserate ist wieder bei 600mb/s im SATA Limit, Schreibrate pendelt sich bei ca. 180mb/s ein. Scheinbar brauchte die SSD einige Zeit um intern weiter zu arbeiten und alle Zellen zu discarden.
Trotzdem kommen die QVOs mit dem CEPH Workload nicht klar, schade.
Gruß, Christian
nach Durchführung eines "bkldiscard /dev/sdx" im Linux hatte sich ja keine unmittelbare Änderung gezeigt. Das sieht nun nach 2 Tagen anders aus. Leserate ist wieder bei 600mb/s im SATA Limit, Schreibrate pendelt sich bei ca. 180mb/s ein. Scheinbar brauchte die SSD einige Zeit um intern weiter zu arbeiten und alle Zellen zu discarden.
Trotzdem kommen die QVOs mit dem CEPH Workload nicht klar, schade.
Gruß, Christian
Zitat von @gdv-it:
Kurze Rückmeldung, für andere Betroffene.
nach Durchführung eines "bkldiscard /dev/sdx" im Linux hatte sich ja keine unmittelbare Änderung gezeigt. Das sieht nun nach 2 Tagen anders aus. Leserate ist wieder bei 600mb/s im SATA Limit, Schreibrate pendelt sich bei ca. 180mb/s ein. Scheinbar brauchte die SSD einige Zeit um intern weiter zu arbeiten und alle Zellen zu discarden.
Kurze Rückmeldung, für andere Betroffene.
nach Durchführung eines "bkldiscard /dev/sdx" im Linux hatte sich ja keine unmittelbare Änderung gezeigt. Das sieht nun nach 2 Tagen anders aus. Leserate ist wieder bei 600mb/s im SATA Limit, Schreibrate pendelt sich bei ca. 180mb/s ein. Scheinbar brauchte die SSD einige Zeit um intern weiter zu arbeiten und alle Zellen zu discarden.
Ist auch nicht verwunderlich. Der Vontroller muß ja erstmal die ganze "Löschwarteschlange" abarbeiten.
lks
Ich war trotzdem verwundert das auch die Leserate der SSD so stark einbricht. Vermutlich war der Controller aber einfach nur beschäftigt.
Ich war trotzdem verwundert das auch die Leserate der SSD so stark einbricht. Vermutlich war der Controller aber einfach nur beschäftigt.
"Löschen" ist halt auch Arbeit für den.
lks
