Hallo Fabian
Also ich habe diesem Thema jetzt nochmals etwas Zeit gewidmet, und zwar kam folgendes dabei heraus.
Nachdem ich alle pve* Dienste sowie die Prozesse(pve-ha-lrm/pve-ha-crm) beendete, konnte ich dank "fatrace -c" sehen das durch den cron Daemon noch etwas aufgerufen wurde was ich letztes mal übersehen hatte. Durch beenden des cron Dienstes verschwanden dann auch die permanenten txg_writes alles 5s und auch diese Meldung im log "ipcc_send_rec failed: Connection refused" verschwand damit.
Also das Ergebins daraus ist, das ZFS nicht daran Schuld ist und das kleinere Übel wie ich es zuvor in diesem Thread Beschrieb somit weg fällt.(Jetzt nur noch ca. 120MB/Tag Schreibzugriff) Weil bei meinem letzten Test vermutlich der weiterlaufende crond weitere Schreibzugriffe verursachte entstand damals ca. 1GB/Tag.
Also bleibt zum Schluss nur noch das "Große Übel" bestehen, wofür ich das Proxmox Team bitten möchte hier Optimierungen vor zu nehmen. Wie in den letzten Postings von morph027 und mir zu sehen scheint hierfür der ständige Schreibzugriff auf "config.db-wal" verantwortlich zu sein.
Vielleicht lässt sich diese Datei ja auch auf ein virtuelles Dateisystem im RAM verlagern? (zB tmpfs)
Weiters "fatrace" welches bei Verwendung von ZFS als Dateisystem nicht so arbeitet wie es laut man page sollte.
Kann ich hierfür irgendwo einen Bugreport veranlassen?
Also ich habe diesem Thema jetzt nochmals etwas Zeit gewidmet, und zwar kam folgendes dabei heraus.
Nachdem ich alle pve* Dienste sowie die Prozesse(pve-ha-lrm/pve-ha-crm) beendete, konnte ich dank "fatrace -c" sehen das durch den cron Daemon noch etwas aufgerufen wurde was ich letztes mal übersehen hatte. Durch beenden des cron Dienstes verschwanden dann auch die permanenten txg_writes alles 5s und auch diese Meldung im log "ipcc_send_rec failed: Connection refused" verschwand damit.
Also das Ergebins daraus ist, das ZFS nicht daran Schuld ist und das kleinere Übel wie ich es zuvor in diesem Thread Beschrieb somit weg fällt.(Jetzt nur noch ca. 120MB/Tag Schreibzugriff) Weil bei meinem letzten Test vermutlich der weiterlaufende crond weitere Schreibzugriffe verursachte entstand damals ca. 1GB/Tag.
Also bleibt zum Schluss nur noch das "Große Übel" bestehen, wofür ich das Proxmox Team bitten möchte hier Optimierungen vor zu nehmen. Wie in den letzten Postings von morph027 und mir zu sehen scheint hierfür der ständige Schreibzugriff auf "config.db-wal" verantwortlich zu sein.
Vielleicht lässt sich diese Datei ja auch auf ein virtuelles Dateisystem im RAM verlagern? (zB tmpfs)
Weiters "fatrace" welches bei Verwendung von ZFS als Dateisystem nicht so arbeitet wie es laut man page sollte.
Kann ich hierfür irgendwo einen Bugreport veranlassen?
Die Config-DB im RAM ware extrem ungünstig...Das geht nicht, du würdest ja immer das Risiko eingehen, die Konfiguration zu verlieren. Mir fällt zwar gerade nichts besseres ein, aber mal sehen. Letztendlich zielt PVE nicht auf den Heimmarkt ab. Unsere gekauften Server auf Arbeit mit ordentlichen Enterprise SSDs stört das nicht.
Ich kann mir nicht vorstellen das sich permanent etwas an meiner Konfiguration ändert, wenn niemand drauf verbunden ist und auch keine VMs angelegt sind! (Und wenn sich nichts ändert, warum wird etwas geschrieben?)
Also vermute ich kann es sich nur um Statuszustände der einzelnen Dienste vom Host handeln, alles dies könnte sehr wohl im RAM vorgehalten werden.
Denn wenn der Host abgestürzt ist, werden auch Statuszustände im RAM nicht mehr benötigt.
Vor allem würde mich interessieren was genau hier ständig geschrieben wird?
(Es sind wohlgemerkt 11GB/Tag im Leerlauf ohne VMs)
Auch ich verwende Enterprise SSDs im echt Einsatz, aber es geht ja nicht nur darum das wear-out einer SSD zu strapazieren. Sondern jeder solche unnötige in meinen Fall HDD-Zugriff bedeutet das alle meine Zugriffe auf Nutzdaten durch solche unnötigen Schreib-Zugriffe gebremst werden.
Also vermute ich kann es sich nur um Statuszustände der einzelnen Dienste vom Host handeln, alles dies könnte sehr wohl im RAM vorgehalten werden.
Denn wenn der Host abgestürzt ist, werden auch Statuszustände im RAM nicht mehr benötigt.
Vor allem würde mich interessieren was genau hier ständig geschrieben wird?
(Es sind wohlgemerkt 11GB/Tag im Leerlauf ohne VMs)
Auch ich verwende Enterprise SSDs im echt Einsatz, aber es geht ja nicht nur darum das wear-out einer SSD zu strapazieren. Sondern jeder solche unnötige in meinen Fall HDD-Zugriff bedeutet das alle meine Zugriffe auf Nutzdaten durch solche unnötigen Schreib-Zugriffe gebremst werden.
Nur mal so als weitere Info habe ich ähnliche Erfahrungen wie @0815user gemacht:
Ich habe mich unabhängig von dem Ticket hier auch um das Thema gekümmert, da ich ähnliche Probleme auf einer Box hatte und dort macht wir das ständige Schreiben der Konfig-Datenbank auch die SSD kaputt. Ein über Tage laufendes iotop hat mir auch der pmxcfs die meisten Schreibzugriffe auf die Platte. Auf nicht-enterprise SSDs, bei denen es anscheinend (zumindest bei meinen SSDs) eine hohe Write-Amplification gibt schreibt der wirklich 'wie blöd' auf die Platte. Die Write-Amplification sieht man prima wenn man iotop neben z.B. iostat oder dstat stellt und wirklich sieht, dass wenige kleine Änderungen viele Änderungen auf der Platte selbst verursachen.
Bei mir sind es ca. 220 KB/sec ständiger Schreiblast, was 18 GB/sec verursacht.
Ich habe mich unabhängig von dem Ticket hier auch um das Thema gekümmert, da ich ähnliche Probleme auf einer Box hatte und dort macht wir das ständige Schreiben der Konfig-Datenbank auch die SSD kaputt. Ein über Tage laufendes iotop hat mir auch der pmxcfs die meisten Schreibzugriffe auf die Platte. Auf nicht-enterprise SSDs, bei denen es anscheinend (zumindest bei meinen SSDs) eine hohe Write-Amplification gibt schreibt der wirklich 'wie blöd' auf die Platte. Die Write-Amplification sieht man prima wenn man iotop neben z.B. iostat oder dstat stellt und wirklich sieht, dass wenige kleine Änderungen viele Änderungen auf der Platte selbst verursachen.
Bei mir sind es ca. 220 KB/sec ständiger Schreiblast, was 18 GB/sec verursacht.
leicht irreführend enthält die config.db nicht nur konfiguration, sondern auch (fast) alles andere was in /etc/pve enthalten ist - das sind unter anderem auch cluster-weite locks und synchronisierte status dateien (z.b. für die HA services).
jein - für manche dateien stimmt das eventuell (s.u.).
ich hab das bereits kurz intern diskutiert, um hier eventuell für bestimmte use cases besseres verhalten zu bekommen (vereinfachte darstellung):
- die hauptursache für regelmäßiges schreiben in die DB (wenn sonst nichts los ist) ist der lrm-manager, welcher alle 5 sekunden einen timestamp aktualisiert (watchdog funktionalität). eventuell lässt sich dies durch zusätzliche logik abfedern, sofern kein bedarf für den lrm besteht, z.b. weil kein cluster oder keine HA ressourcen konfiguriert sind, für den HA-fall brächte das allerdings keine verbesserung
- eventuell ließe sich das pmxcfs diesbezüglich anpassen, damit diese status datei (die im node-ausfalls fall sowieso nicht mehr aktuell ist) tatsächlich nur in memory gehalten wird - allerdings erfordert dies AFAICT neue zusätzliche logik, da bis jetzt dateien immer entweder nur "in-memory und lokal" oder "synchronisiert und auf disk" sind, in diesem fall bräuchten wir aber "synchronisiert aber nicht persistent"
von heute auf morgen wird sich hier also fürchte ich nichts tun (und wie immer kann sein, dass sich das ganze bei genauerer betrachtung als nicht oder nicht so durchführbar erweist).
hast du mit ashift u./o. recordsize experimentiert ? was für ein zpool setup hattest du (raidz?)? im normalfall sollte sich write amplification einigermaßen in den griff kriegen lassen.. oder war das ganze auf "normalem" ext4?
Es war ein RAID0 auf einer Platte
-p) im Notebook - nur da sind Consumer-SSDs drin (also normal 4K Blockgröße ohne Experimente auf dem ROOT dateisystem). Musste wegen dem extremen Verschleiß die SSD schon ausbauen.