ZFS: Ungewöhnlich viele Writes

[irrwisch]

Hallo zusammen,

ich habe mir kürzlich ein Proxmox 6.1 auf einem SSD Mirror bestehend aus zwei SSDs aufgesetzt.
Bei den SMART Werten ist mir neulich aufgefallen, dass die Total LBAs Written für meinen Geschmack zu schnell ansteigen.
Aktuell so 50GB am Tag, bei sehr geringer Aktivität auf dem System.

zpool iostat 1 zeigt mir, dass alle 5 Sekunden etwa 5MB geschrieben werden

rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 201 0 5.23M
rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 205 0 4.37M
rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 0 0 0
rpool 25.6G 206G 0 230 0 5.92M
rpool 25.6G 206G 0 5 7.99K 95.9K
rpool 25.6G 206G 0 1 0 16.0K


Ich habe dann iotop -a laufen lassen, aber diese regelmäßigen Writes alle 5 Sek korrelieren mit nichts, was ich im iotop sehen kann. Im iotop steigen die Akkumulierten Writes nur relativ langsam an, keine Spur von ~50 GB am Tag.

Hat jemand eine Idee wie man herausfinden kann, was diese regelmäßigen Writes alle 5 Sekunden verursacht?

Ich habe schonmal die Recordsize des Zpools von 128k auf 16k runtergesetzt, das scheint aber keinen Effekt zu haben.

Vielen Dank schon mal und viele Grüße
Julien

 

[LnxBil]

Bei den SMART Werten ist mir neulich aufgefallen, dass die Total LBAs Written für meinen Geschmack zu schnell ansteigen.
Aktuell so 50GB am Tag, bei sehr geringer Aktivität auf dem System.

Ich schätze das sind Consumer oder Prosumer SSDs? Die sind nicht geeignet für ZFS, da die kleinste Einheit, die diese SSDs schreiben können mehrere MBs sind und bei jedem Blockupdate dann gleich mehrere MB geändert werden. Über die Zeit kommen dann diese utopischen Werte zusammen. Intern schreibt PVE die eigene Datenbank in /var/lib/pve-cluster ständig und daher kommen die vielen writes auch wenn das System eigentlich nix macht.

 

[fireon]

Bitte nur Enterprise hierfür verwenden. Wir hatten das mal mit ner Samsung Consumer SSD getestet, nach 5 Monaten waren alle defekt und alle Blöcke inkl. Reserve verbraucht.

 

[Vengance]

Gibt es hier seitens der Config irgendwie Optimierungsmöglichkeiten?
Ich habe hier beispielsweise einen kleinen Homeserver mit wenig VMs im Auge, da wäre es praktisch, auch reguläre Consumer SSDs verwenden zu können.

 

[LnxBil]

Gibt es hier seitens der Config irgendwie Optimierungsmöglichkeiten?

Man könnte vielleicht mit den internen Einstellungen von ZFS rumspielen und so z.B. das Transaction Group Timeout höher setzen (zfs_txg_timeout), was dann mehr SYNC-Writes cachet und somit bei einem Ausfall die Menge der verloren Daten erhöht. So kann man aber auf jeden Fall einige I/Os sparen. Du wirst aber wahrscheinlich nirgends eine offizielle (seitens PVE oder ZoL) Anleitung erhalten, denn ZFS auf nicht-Enterprise SSDs ist nach wie vor nicht gut (weder performant, noch langlebig). ZFS funktioniert einfach anders als andere Dateisysteme und non-Enterprise SSDs sind nicht dafür ausgelegt.

 

[tobi471]

Hallo zusammen,

ich würde mich für eine Optimierung ebenfalls interessieren. Ich habe seit 4 Monaten eine Samsung 860 EVO in Betrieb. Meine Werte sind folgende:


Gruß Tobi

 

[irrwisch]

Dito, bei mir sinds auch Samsung Evos.

Also es scheint wirklich so zu sein, die 5 MB Writes die ich alle 5 Sekunden sehe kommen von der Datei /var/lib/pve-cluster/config.db-wal die exakt alle 5 Sekunden neu geschrieben wird und ca 5MB groß ist.

Ich bin mir nicht sicher ob man da die Schuld wirklich auf ZFS schieben kann.
Bevor ich mir den Server zusammengestellt habe hab ich einiges rumrecherchiert und bei Reddit hieß es immer wieder, moderne Consumer SSDs und ein aktuelles ZFS sei kein Problem mehr.

Mir scheint es eher höchst suboptimal zu sein, dass Proxmox alle 5 Sekunden eine 5 MB Datei komplett schreibt. Das ist einfach sehr unschön und ist auch für eine Enterprise SSD nicht gerade optimal.
Ich glaube, wenn man das irgendwie abstellen könnte hätte man da gar kein so großes Problem mehr mit Consumer SSDs auch über einen längeren Zeitraum (vorrausgesetzt, dass auf dem System ansonsten eher wenig geschrieben wird, wie in meinem Fall).

edit: hier noch was interessantes dazu gefunden:
https://forum.proxmox.com/threads/pmxcfs-writing-to-disk-all-the-time.35828/
Die beiden HA Dienste habe ich mal gestoppt da ich HA eh nicht nutze. Nun wird die config.db-wal nur noch genau 1 mal pro Minute geschrieben.
Das sollte sich deutlich bemerkbar machen bei den Total Bytes Written. Ich werde das jetzt mal die nächste Zeit beobachten.

edit2: Ne ich nehme meine Aussage zurück und behaupte das Gegenteil
Im zpool iostat hab ich immernoch die selben writes alle 5 Sekunde, gesehen. Es ist das zfs_txg_timeout welches die Writes produziert. Ich hab das jetzt zum testen mal etwas höher gesetzt.

 

[tobi471]

Hallo zusammen,

ich habe bei mir mal das

• zfs_txg_timeout temporär über die shell angepasst mit
  

  echo 60 >/sys/module/zfs/parameters/zfs_txg_timeout

Dies hat dazu geführt, dass im "Leerlauf" nur noch alle 60 Sekunden ein Schreibvorgang stattfindet. Dies führt zu einer enormen Verbesserung der LBA Written. (Ca. 1,9 GB am Tag)

Ich wollte dies nun unter /etc/modprobe.d/zfs.conf ändern. Hierzu habe ich folgendes eingetragen:

 options zfs zfs_txg_timeout=60

Jedoch wird dies bei einem Neustart des Servers nicht angewendet. Mache ich hier etwas falsch?

Gruß Tobi

 

[LnxBil]

Mir scheint es eher höchst suboptimal zu sein, dass Proxmox alle 5 Sekunden eine 5 MB Datei komplett schreibt.

Es ist ja auch keine 5 MB Datei. Schau mal wie groß die Datei bei dir ist. In einem Cluster mit 200 Maschinen ist sie bei mir gerade mal ein halbes MB groß. Die 5 MB Writes kommen von der Write Amplification der SSD.

Das ist einfach sehr unschön und ist auch für eine Enterprise SSD nicht gerade optimal.

Quatsch. Die Enterprise SSD hat damit keinerlei Probleme. Meine MZ7WD960 haben nach knapp 7 Jahren Dauereinsatz gerade mal 66 TB written bei einer Drive Health von 97%. Meine interne Blöcke sind halt nur 8 KB groß, keine zig MB wie bei den Billig SSDs.

Ich glaube, wenn man das irgendwie abstellen könnte hätte man da gar kein so großes Problem mehr mit Consumer SSDs auch über einen längeren Zeitraum

Jeder einzelne Write schreibt mehr als der Write selbst. Das Problem geht ja nicht magisch weg. Meine 750 EVO hat auch bereits 52 TB written und da ist kein PVE drauf, "nur" ZFS und das ist ein Desktop, da wird auch nicht viel geschrieben. Die Teile sind einfach Müll für ein CoW-basiertes System. Kauf dir einfach gebrauchte Enterprise SSDs und dann hast du auch wieder Spaß mit ZFS.

 

[LnxBil]

Ich wollte dies nun unter /etc/modprobe.d/zfs.conf ändern. Hierzu habe ich folgendes eingetragen:

 options zfs zfs_txg_timeout=60

Jedoch wird dies bei einem Neustart des Servers nicht angewendet. Mache ich hier etwas falsch?

Hast du das initrd neu gebaut? Falls nein ist es klar, dass es nicht geht.

 

[tobi471]

Hast du das initrd neu gebaut? Falls nein ist es klar, dass es nicht geht.

Vielen Dank für den Hinweis. Dies hatte ich aber schon durchgeführt und der Timeout wurde beim Neustart trotzdem wieder auf "5" gesetzt.

 

[LnxBil]

Vielen Dank für den Hinweis. Dies hatte ich aber schon durchgeführt und der Timeout wurde beim Neustart trotzdem wieder auf "5" gesetzt.

Falls du ein EFI-System hast, wäre vielleicht ein pve-efiboot-tool refresh noch notwendig. Im Prinzip funktioniert dein Ansatz, zumindest hat er gerade bei mir funktioniert. Hast du vielleicht mehrere Konfigurationsdateien für ZFS in /etc/modprobe.d?

 

[tobi471]

Falls du ein EFI-System hast, wäre vielleicht ein pve-efiboot-tool refresh noch notwendig. Im Prinzip funktioniert dein Ansatz, zumindest hat er gerade bei mir funktioniert. Hast du vielleicht mehrere Konfigurationsdateien für ZFS in /etc/modprobe.d?

ich habe nur eine zfs.conf unter /etc/modprobe.d. Leider hat auch ein pve-efiboot-tool refresh nicht zum Erfolg geführt. Oder müssen

pve-efiboot-tool refresh

und

pve-efiboot-tool refresh

direkt nacheinander ausgeführt werden bevor ein Neustart erfolgt?

 

[AndrwHmmr]

Hallo zusammen,

ich habe bei mir mal das

• zfs_txg_timeout temporär über die shell angepasst mit
  

  echo 60 >/sys/module/zfs/parameters/zfs_txg_timeout

Dies hat dazu geführt, dass im "Leerlauf" nur noch alle 60 Sekunden ein Schreibvorgang stattfindet. Dies führt zu einer enormen Verbesserung der LBA Written. (Ca. 1,9 GB am Tag)

Ich wollte dies nun unter /etc/modprobe.d/zfs.conf ändern. Hierzu habe ich folgendes eingetragen:

 options zfs zfs_txg_timeout=60

Jedoch wird dies bei einem Neustart des Servers nicht angewendet. Mache ich hier etwas falsch?

Gruß Tobi

Workaround mit crontab "@ reboot" ?

 

[tobi471]

Workaround mit crontab "@ reboot" ?

Über Crontab ist das natürlich elegant möglich. Danke.

@irrwisch

Wie hast du das Problem mit den LBA written gelöst?

 

[AndrwHmmr]

Ich habe jetzt mal mein Monitoring/Trending auf die Sache angesetzt.
Ich scrape alle 10 Sekunden die data_units_written meiner 970 EVOs (MIRROR).

Wenn ich den Graphen jetzt richtig interpretiere (und andere Rechenfehler ausgeschlossen) dann werden alle 24h ca. 15GB auf die Platten geschrieben.
Momentan läuft dort der Prometheus drauf und noch der Unifi Controller etc.... also eigentlich nichts ungewöhnliches.
Bei der Rate haben die 970 EVOs ihre TBW (300TB) in 54 Jahren erreicht

Ich habe gestern Abend noch das

echo 60 >/sys/module/zfs/parameters/zfs_txg_timeout

gesetzt.

Ich teste dann heute abend oder morgen mal den default von "5" und gucke ob sich was ändert.

 

[LnxBil]

Ich habe jetzt mal mein Monitoring/Trending auf die Sache angesetzt.

gute Idee.

Momentan läuft dort der Prometheus drauf und noch der Unifi Controller etc.... also eigentlich nichts ungewöhnliches.

Bei den meisten würde ich noch eine höhere Write-Back-Time einrichten, sodass mehr im Speicher gehalten wird und somit noch seltener die Disk verwendet wird.

 

[AndrwHmmr]

...
Bei den meisten würde ich noch eine höhere Write-Back-Time einrichten, sodass mehr im Speicher gehalten wird und somit noch seltener die Disk verwendet wird.

Aber das ist doch eigentlich egal wann er die Daten schreibt, die Menge ändert sich ja eigentlich nicht. Okay außer du hast halt so komische Phänomene wie write amplification....

 

[LnxBil]

Aber das ist doch eigentlich egal wann er die Daten schreibt, die Menge ändert sich ja eigentlich nicht. Okay außer du hast halt so komische Phänomene wie write amplification....

Für die Write Amplification ist es immer besser größere Batches zu schreiben, genau das macht man ja in dem man das Transaction Grouping Timeout höher setzt - vorausgesetzt natürlich, das Schreib-Pattern passt. Das ist bei ZFS aber meistens so, denn es werden ja nie Daten geändert, sondern immer nur neu geschrieben.

 

[tobi471]

Ich teste dann heute abend oder morgen mal den default von "5" und gucke ob sich was ändert.

Gibts was neues zu deinen Tests? Ich habe bisher keine negativen auswirkungen durch das Ändern des zfs_txg_timeout bemerkt.