Proxmox LXC: Extreme I/O Delays mit neueren WD SA500 SSD

wario

Member
Apr 6, 2023
23
3
8
Hi Leute, ich schreibe euch mal in der Hoffnung ein paar Lösungen und Ideen zu meinem merkwürdigen Problem zu finden. Kurz: ich habe 2 Server, auf dem einem Performancen die SSDs ohne Probleme, auf dem anderen Server habe ich mit wirklich hohem i/o Delay zu kämpfen, obwohl auf beiden, die selbe Anwendung läuft, und sie sonst auch identisch aufgesetzt sind.

Von vorne weg, mir ist klar, das Consumer SSDs wie die SA500 nicht unbedingt ideal für ZFS Systeme sind, jedoch geht es mir hier nicht um die maximale Performance da das Budget hier auch ein gewisse Rolle spielt. Das Problem ist einfach, dass auf dem einem System die SA500 ohne grössere Probleme arbeiten, auf dem anderen aber nicht. Ich entschuldige mich auch, wenn ich hier keine Fachausdrücke verwende, nicht bis is Detail in die Technik blicke, und/oder sehr Laienhaft die Thematik beschreibe, und auch nicht mit Benchmarks komme. Falls diese erwünscht sind, liefere ich die nach, wenn mir jemand sagt, was er für Benchmarks braucht, um die Situation besser beurteilen zu können. Ich selber bin nur Hobby Sysadmin und betreibe ein paar Server aus Spass an der Freude. Auch weiss ich, dass hier ziemliche Profis unterwegs sind, also entschuldigt mich, wenn etwas fehlt, oder ich etwas zu ungenau beschreibe, oder was auch immer :)

Nun die lange Version:

Problem:
Ich betreibe zwei Proxmox-Server mit der aktuellen Version 8.3.4 und beobachte massive Unterschiede in der I/O-Performance bei identischer Software und eigentlich gleichen SSDs. Wenn man es genauer nimmt: eigentlich nicht identisch, weil a: auf Server 1 die Software massiv mehr zu tun hat, als auf Server 2, und b: die WDSA500 auf Server 2 einer neueren Version entsprechen. Sie werden zumindest anders bezeichnet beim Disk Check unter pve --> Disks

Kommen wir zu den Problemen und dem Setup:

Server 1 (keine Probleme):
- Hardware:
- 2x WDSA500 (WDC_WDS200T1R0A-68A4W0) im ZFS-Mirror
- 128GB DDR4 RAM @ 3200 MHz
- Anwendungen:
- grössere Bitcoin- und Lightning-Node in einem LXC-Container mit Ubuntu 24.04, über 60 Kanäle zu anderen Nodes, sehr hohes Routing aufkommen, sehr hohe Schreib und Leselast
- Performance:
- Keine I/O Delays**, keine Performanceprobleme. Beim starten und initialisieren der Node evt 5% i/o delay laut Proxmox. Während dem Betrieb der Node, i/o delax von höchstens 2-3%
- Die Node ist nach einem Neustart nach ca 2 Minuten Betriebsbereit

Server 2 (massive I/O Delays & Container-Freezes):
- Hardware:
- 1x WD SA500 (WD_Red_SA500_2.5_2TB) (neuere Version)
- AMD Ryzen **5700G**
- 128GB DDR4 3200MHz RAM
- Anwendungen:
- kleinere Bitcoin- und Lightning-Node ebenso in einem LXC-Container mit Ubuntu 24.04 (die Node hat aber im Vergleich zu Node 1 auf Server 1 praktisch nichts zu tun da sie nur 4 Kanäle hat, und praktisch kein Routing betrieben wird)
- Probleme:
- Extreme I/O Delays beim Starten der Node bis zu 40% i/o Delay beim Start und initialisieren der Node.
- Über den Tag hinweg heftige I/O-Spitzen, sodass manche Docker-Container hängen bleiben (Datenbank-Locks in den Containern)
- `lndg (ein Rebalancer für Bitcoin Lightning Channels)` bleibt über Nacht häufig komplett stehen. Teilweise gehen die spitzen beim Betrieb auf 18% und mehr
- Die Node ist nach einem Neustart teilweise erst nach 10 Minuten betriebsbereit


Zusätzliche Beobachtungen:
1. Mein Kumpel hat exakt dieselben neuen WD SA500 SSDs (selbe Bezeichnung wie auf Server 2) und genau das gleiche Problem. Die Nodesoftware ist die selbe.
- Auch neueste PVE-Version
- er betreibt wie ich auf Server 1 ein ZFS Mirror-Setup von 2x SA500
- AMD Ryzen 5500G
- 32GB DDR4 RAM

2. Alle Systeme laufen mit ZFS
3. Die alten WDSA500 auf dem Server 1 haben keinerlei Probleme, selbst unter Last.
4. Die Nodesoftware ist auf allen System identisch und läuft auf Ubuntu 24.04


Hintergrund zu den Anwendungen:
- Bitcoin Full Node (bitcoind): Liest und schreibt intensiv auf die Disk (Blockdaten, Indexe, Mempool etc.).
- Lightning Node (lnd): Arbeitet mit kleinen, häufigen Lese- und Schreibzugriffen, was SSDs mit schlechter Random-Write-Performance stark belasten kann. Stark datenbanklastige Anwendung.

---

Fragen:
1. Gibt es bekannte Unterschiede zwischen der alten und neuen WD SA500 bezüglich Firmware oder Performance unter ZFS?
2. Hat jemand ähnliche I/O-Probleme mit der neueren Versionen der WD SA500?
3. Hat jemand ne Idee, wieso es zu derart grossen i/o Last Differenzen kommen kann bei eigentlich dem selben SSD Model?

Ich bin für jede Hilfe oder Anregung dankbar! Ich suche schon seit Wochen nach dem Problem, aber im Internet finde ich nichts. Die Software ist identisch. Die LXC Container Einstellungen unterscheiden sich nicht. Auch gibt es keine Spezialkonfigurationen auf Server 2.
Jemand hat empfohlen, mal auf System 2 den ZFS sync auf disabled zu stellen, jedoch ist das nicht gerade optimal da LND bzw die Lightning Node Datenbanken verwendet, und ein Verlust der Daten bei einem Kernel-Crash katastrophal enden könnte. Ausserdem erschliesst sich mir nicht, wieso die einen Disks mit voller ZFS Funktionalität keine Probleme machen, die anderen im zweiten Server jedoch schon.
Die beiden Server sind zwar an einer UPS, riskieren möchte ich dies aber irgendwie nicht.

Also nun, ich hoffe ich konnte die Situation einigermassen genau beschreiben, und hoffe, dass der ein oder andere evt nen Tipp für mich hat.

Greetings

Wario
 
Last edited:
Hi, bei den Consumer SSDs werden in den Modellreihen auch verscheidene Flash Bausteine verwendet und auch das Caching ist unter Umständen unterschiedlich.
Was du so beschreibst, klingt eindeutig nach schlechter Performance der SSDs. Ich würde in deinem Fall kein ZFS nutzen sondern dann lieber ein mdraid Mirror machen und LVM Thin benutzen.
 
Hi, bei den Consumer SSDs werden in den Modellreihen auch verscheidene Flash Bausteine verwendet und auch das Caching ist unter Umständen unterschiedlich.
Was du so beschreibst, klingt eindeutig nach schlechter Performance der SSDs. Ich würde in deinem Fall kein ZFS nutzen sondern dann lieber ein mdraid Mirror machen und LVM Thin benutzen.

Hi Falk, vielen Dank für deine Nachricht. Ich hatte tatsächlich vor, sobald die SSDs durch sind auf Server 1 und 2, auf ein lvm-thin mdraid umzustellen da ich auch die höhere Write Amplification von ZFS im Auge hatte. Ausserdem hab ich mir Kingston DCA600M besorgt.
Spannend ist auch, dass sich die die beiden SSDs im Server 1 der 10% Marke nähern, und immer noch bestens performen, und ich keine Probleme habe.

Die SSD in Server 2 ist wie gesagt n paar Monate halt, und musst bis jetzt nicht wirklich "arbeiten".

Trotz wurmt mich das ganze ziemlich, da die Performanceunterschiede wirklich brutal sind. Ich würde verstehen wenn die andere Modelreihen ein paar Prozent schlechter performen, aber in diesem Ausmass?? Die Software ist auf den neuen Modellen praktisch unbrauchbar.
Ist das kein Rückgabe Grund? Besteht hier Möglichkeit eines Defekts einer bestimmten Modelreihe? Der Kollege der die selben SSDs hat, hab wie gesagt genau die selben Probleme.
 
Bei ZFS auf SSDs kann man auch ein Augenmerkt auf einen Parameter haben:
zfs get atime
Und ein ZFS Pool sollte nur bis ca. 80% Auslastung genutzt werden:
zfs set quota=<value> <pool>
Den 100% Wert kann man sich über zpool list <pool> abfragen.
 
  • Like
Reactions: Johannes S
Hi Falk, vielen Dank für deine Nachricht. Ich hatte tatsächlich vor, sobald die SSDs durch sind auf Server 1 und 2, auf ein lvm-thin mdraid umzustellen da ich auch die höhere Write Amplification von ZFS im Auge hatte. Ausserdem hab ich mir Kingston DCA600M besorgt.
Spannend ist auch, dass sich die die beiden SSDs im Server 1 der 10% Marke nähern, und immer noch bestens performen, und ich keine Probleme habe.

Die SSD in Server 2 ist wie gesagt n paar Monate halt, und musst bis jetzt nicht wirklich "arbeiten".

Trotz wurmt mich das ganze ziemlich, da die Performanceunterschiede wirklich brutal sind. Ich würde verstehen wenn die andere Modelreihen ein paar Prozent schlechter performen, aber in diesem Ausmass?? Die Software ist auf den neuen Modellen praktisch unbrauchbar.
Ist das kein Rückgabe Grund? Besteht hier Möglichkeit eines Defekts einer bestimmten Modelreihe? Der Kollege der die selben SSDs hat, hab wie gesagt genau die selben Probleme.
Leider hat man das auch bei HDDs, Gerade bei den WD Red HDDs gab es beim Revisionswechsel auch große Performanceunterschiede und da gab es auch keine Möglichkeit zum Rückabwickeln. Die theoretischen Werte aus dem Datenblatt schaffen die im entsprechend angepassten Benchmark trotzdem.
Ich habe meine alten Consumer SSDs auch aus dem Testcluster raus geworfen, weil mich die schwankende Performnance so richtig genervt hat.
 
  • Like
Reactions: Johannes S
Ich habe mit älteren M.2 WD Blue sehr schlechte Erfahrung unter Windows gemacht und hatte teilweise diese Delays. Da hat nur geholfen, den unsicheren Cache im Gerätemanager zu aktivieren.

Mit einer Crucial BX500 hatte ich mit Proxmox / ZFS ebenfalls das Problem.

ZFS kann das Problem abschwächen, weil es Write-Cache bietet, bei alten Installationen von Proxmox war das Default-mäßig die Hälfte des RAMs. Wenn das System ausreichend RAM hat, kannst du durchaus ein paar GB in den ZFS Arc schreiben, bevor sich das überhaupt bemerkbar macht. Hast du nur sporadische Schreibzugriffe bleibt es tatsächlich in der Praxis dann oft unbemerkt. Ändert aber nichts daran, dass man an der SSD nicht sparen sollte. Der Mehrpreis für zumindest mal hochpreisige Consumer Geräte ist im Vergleich zur restlichen Hardware (insb. Prozessorleistung) meist marginal.
Hab ich auch gemacht, s.o., würde ich aber nicht mehr so machen.
 
ZFS kann das Problem abschwächen, weil es Write-Cache bietet,
Das kann man schon mal nicht so dastehen lassen. Der ZFS ARC kann auch Async Writes cachen, aber dann auch nicht sooo vile Daten. Der dicke Readchace im ARC entlastet die Disk einfach mit Reads, womit mehr Zeit für Writes da ist. Sync Writes werden IMMER direkt geschrieben. Einzige Ausnahme sind Raidcontroller mit Batteriecache, die cachen auch Sync Writes, das ist aber eine ganz andere Technik.
bei alten Installationen von Proxmox war das Default-mäßig die Hälfte des RAMs. Wenn das System ausreichend RAM hat, kannst du durchaus ein paar GB in den ZFS Arc schreiben, bevor sich das überhaupt bemerkbar macht. Hast du nur sporadische Schreibzugriffe bleibt es tatsächlich in der Praxis dann oft unbemerkt. Ändert aber nichts daran, dass man an der SSD nicht sparen sollte. Der Mehrpreis für zumindest mal hochpreisige Consumer Geräte ist im Vergleich zur restlichen Hardware (insb. Prozessorleistung) meist marginal.
Hab ich auch gemacht, s.o., würde ich aber nicht mehr so machen.
 
  • Like
Reactions: Johannes S
Leider hat man das auch bei HDDs, Gerade bei den WD Red HDDs gab es beim Revisionswechsel auch große Performanceunterschiede und da gab es auch keine Möglichkeit zum Rückabwickeln. Die theoretischen Werte aus dem Datenblatt schaffen die im entsprechend angepassten Benchmark trotzdem.
Ich habe meine alten Consumer SSDs auch aus dem Testcluster raus geworfen, weil mich die schwankende Performnance so richtig genervt hat.

Heisst also ich muss mich damit abfinden und kann praktisch nichts daran rütteln. Das finde ich schon harten Tobak.
Die Node 1 hat wirklich heftigst zu arbeiten. 1800TB mussten die beiden Disks jetzt in einem Jahr schreiben während des Betriebs, und bis heute machen sie keine Mätzchen.

Node 2 auf Server 2 hat praktisch nichts zu tun, und die SSD kotzt schon beim starten und initialisieren von bitcoincore ab. Was sind den das für riesengrosse Unterschiede in der Fertigung bzw der NAND Chips??

Naja dann bleibt mir wohl nichts anderes, als auf ZFS zu verzichten. Die Write Amplifications sind gerade in dieser Anwendung die Ich betreibe jenseits von gut und böse. host_Writes bin ich bei 400TB, und nand_written bei 1800TB, ich verheize pro Jahr also 2 Paar WDSA500

Darum jetzt auch die DC600M für die Hauptnode, jedoch hab ich auch keine Lust dass die nach 2 Jahren durch ZFS bereits wieder tot sind.
Neverthless, Proxmox unterstütz ja selber leider kein mdraid. Ich hab mir mal die Befehle zusammengesucht, kannst du evt kurz drüber schauen ob ich des so richtig machen?

Code:
apt update && apt install -y mdadm

Code:
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdX /dev/sdY

überprüfen mit:

Code:
cat /proc/mdstat

Damit das RAID nach einem Neustart erhalten bleibt, schreibe Ich die Konfiguration in die mdadm.conf:

Code:
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u

LVM Group und Thinpool kann ich dann im GUI von PVE selber erstellen richtig?
 
Last edited:
Naja dann bleibt mir wohl nichts anderes, als auf ZFS zu verzichten.
Darum jetzt auch die DC600M für die Hauptnode, jedoch hab ich auch keine Lust dass die nach 2 Jahren durch ZFS bereits wieder tot sind.

Mach' dich nicht verrückt. Ich würde lieber mehr disks verschleißen oder eben die teuren, als auf ZFS zu verzichten.
Wenn dein Kumpel den gleichen Effekt mit der gleichen Charge/Version der SSD hat, dann liegt es ziemlich wahrscheinlich einfach an der Charge.

Was sind den das für riesengrosse Unterschiede in der Fertigung bzw der NAND Chips??
Anders: es wird oft verbaut was gerade lieferbar und billig ist. Wenn 3 Cent gespart werden können, reiben sich Manager die Hände. War damals mit dem heimlichen untermogeln von SMR bei Drehplatten auch so ein Nümmerchen.
 
  • Like
Reactions: Johannes S
Die DC600M schreibst Du schon nicht so schnell kaputt. Ich habe insgesamt ca. 40 Stück in PVEs und PBS verbaut mit teils sehr hoher Last. Der höchste Wearout liegt atm bei 2% auf einem PVE, der mehrere Windows Server (Terminalserver & SQLs) bereitstellt.
 
Kann man machen.

Allerdings verliert man dann ein halbes Dutzend Features, die andere Filesysteme nicht so einfach in vergleichbarer Güte liefern. Englisch: https://forum.proxmox.com/threads/f...y-a-few-disks-should-i-use-zfs-at-all.160037/

Bin jetzt auf der neuen Node auf die DC600M umgestiegen, und hab mich doch wieder für ZFS entschieden. Da die Anwendung stark datenbanklastig ist
(bbolt) hab ich die recordsize auf 32K gesenkt, xattr auf sa gesetzt und atime wie von @news angemerkt ebenso deaktivert.

Mit diesen 3 Tipps konnte ich den i/o delay auf den schrottigen WDSA500 auf der Zweitnode ebenso etwas reduzieren.

Ich bin immer noch ziemlich entäuscht von diesem massiven Qualitätseinbruch der WD SSDs, ich dachte eigentlich, damit kaufst a bissel etwas besseres als Standard 0815 SSDs die es so gibt, aber anscheinend war das ja mal so richtig n Griff ins Klo, und Western Digital bekommt nach dieser Geschichte kein Geld mehr von mir.

@cwt

Naja was heisst schnell, sicher nicht so schnell wie die WDs allemale, aber ja auf der Routing Node werden 400TB pro Jahr geschrieben und ZFS hat daraus 1800 gemacht. Wenigstens haben sie länger gehalten als was offiziell versprochen worden ist (1400TBW). Auf einer waren noch 6% übrig, auf der anderen sogar noch 24% (was mich auch schon gewundert hatte da beide im Mirror, aber ja, da sieht man ja auch schon nen dicken Unterschied in der Chipgüte auf der selben Modelserie)
 
Last edited:
  • Like
Reactions: UdoB
recordsize auf 32K gesenkt, xattr auf sa gesetzt und atime wie von @news angemerkt ebenso deaktivert.
autotrim könnte für den pool/für dich noch interessant sein, das nutze ich auch gern. Nach kurzer Wartezeit kann man mit zpool iostat -r rpoolin der vorletzten Spalte nachgucken.
 
autotrim könnte für den pool/für dich noch interessant sein, das nutze ich auch gern. Nach kurzer Wartezeit kann man mit zpool iostat -r rpoolin der vorletzten Spalte nachgucken.

Hab ich auch schon gelesen, aber zfs kennt den Befehl nicht,
erscheint auch nicht in der Liste.
 
aber zfs kennt den Befehl nicht,
Pool!

Code:
~# zpool get autotrim rpool
NAME   PROPERTY  VALUE     SOURCE
rpool  autotrim  off       default
 
  • Like
Reactions: wario
Sorry, schrieb ja ich bin nur hobbysysadmin :D
Man wächst mit seinen Aufgaben. ;)
zpool = hierarchisch über dem zfs/dataset
zpool list <- zeigt die Bruttokapazität
zpool get all rpool <- nachgucken, welche Flags und Features aka properties es auf dem pool gibt und was eingestellt ist
zpool get autotrim rpool <- explizit ein einzelnes property betrachten
zpool get size,health,autotrim rpool <- explizit mehrere properties betrachten
Nach gleichem Schema mit zpool set ... einstellen.

zfs = hierarchisch unter dem zpool
zfs list <- zeigt die Nettokapazität und die bestehenden datasets
zfs get all rpool/ROOT/pve-1 <- nachgucken, welche Flags aka property (keine Features auf datasets!) es auf dem pool gibt und was eingestellt ist
Ebenso auch hier nach gleichem Schema der Rest.

Ich bin immer noch ziemlich entäuscht von diesem massiven Qualitätseinbruch der WD SSDs, ich dachte eigentlich, damit kaufst a bissel etwas besseres als Standard 0815 SSDs die es so gibt, aber anscheinend war das ja mal so richtig n Griff ins Klo, und Western Digital bekommt nach dieser Geschichte kein Geld mehr von mir.
Den Griff ins Klo hat man leider immer mal mittendrin, egal bei welchem Hersteller. Auch dafür sind Foren nicht mit Gold aufzuwiegen, wo man sich Empfehlungen für sowas aussprechen kann. Manchmal gibts noch die kleine Chance, dass der Hersteller neue Firmware bereitstellt wenn sich grobe Bugs eingeschlichen haben. Wenn aber die Chips einfach minderwertig sind, muss man damit leben oder sie zurückgeben. Würde ich in deinem Fall machen, wenn dafür die Frist noch nicht abgelaufen ist. Aber vorher natürlich einmal sanitize drüber. ;)
 
  • Like
Reactions: Johannes S and UdoB