ZFS txg schreibt alle 5 Sekunden auch im Leerlauf

[0815user]

Liebe Community
Ich habe aktuell ein Proxmox VE 4.3 mit ZFS auf einem neuen Server mit 2 HDDs aufgesetzt(ein gespiegelter ZFS pool "rpool"), und obwohl die VMs heruntergefahren sind und der Server auch sonnst im Leerlauf ist, höre ich alle 5 Sekunden ein Festplattengeräusch.
Das geht so ununterbrochen den ganzen Tag über, und da mir dies eigenartig vor kam habe ich auch mal mit smartctl nachgesehen und dabei bemerkt das es sich um schreib Zugriffe handelt.(Total_LBAs_Written zählt jedes mal hoch)

Nach ein paar Stunden Beobachtung komme ich hochgerechnet auf einen Tag auf knapp 11GB Schreibzugriffe fürs nichts tun, was mir als nicht richtig erscheint!
Bei SSDs würde ich mir bereits Sorgen machen, wegen einer unnötigen Abnutzung, sind immerhin knapp 4 TB pro Jahr.

Auch mit iotop sehe ich während dieser HDD Zugriffe immer den txg_sync aufleuchten.
Ich habe daher mal Testweise den txg_sync Intervall auf das vierfache(20s) gestellt, und siehe da ich hatte plötzlich nur mehr ca. 1/4 der Schreibzugriffe(knapp 3GB pro Tag) verzeichnet.

Hat sonnst jemand auch diese Erfahrung gemacht, oder gibt es eine Begründung dafür das es entgegen meiner Vermutung normal ist bei ZFS?

 

[fabian]

dabei wird es sich vermutlich um logs, status-files und statistiken handeln - txg_sync ist lediglich der "flush" prozess von zfs, die eigentlichen writes kommen von wo anders das intervall hochzuschrauben, erhöht die wahrscheinlichkeit, dass im ausfallsfall daten weg sind.

deine 11Gb pro tag sind auf die sekunde gerechnet nur ~114Kb/s , das scheint mir jetzt nicht wahnsinnig viel. zum minimieren wäre aber der erste schritt, herauszufinden was wirklich schreibt.

 

[0815user]

Hallo Fabian
Danke für deine Rückmeldung, aber das es sich um "logs, status-files und statistiken" handeln soll scheint mir nicht ganz Schlüssig, denn wenn ich nur den txg timeout auf 20s stelle werden dann plötzlich nur ein viertel der Daten geschrieben?

Ich hab jetzt auch mal kurz nachgesehen wie es sich dabei mit dem Datenzuwachs verhält, und zwar obwohl die Total_LBAs_Written hochzählen blieb die Datenmenge gleich wenn ich alle gemounteten Volumes mittels "df" betrachte. Kann erst Abends wieder einen längeren Test machen über ein paar Stunden.

Gäbe es denn eine Möglichkeit mit einem ZFS Kommando mit zu schneiden was für Dateien geschrieben werden?

 

[fabian]

Hallo Fabian
Danke für deine Rückmeldung, aber das es sich um "logs, status-files und statistiken" handeln soll scheint mir nicht ganz Schlüssig, denn wenn ich nur den txg timeout auf 20s stelle werden dann plötzlich nur ein viertel der Daten geschrieben?

weil gerade solche dateien wie status und statistiken meistens schnell überschrieben werden, d.h. wenn du weniger oft "echt" schreibst werden weniger daten tatsächlich geschrieben. einfaches beispiel wäre eine status datei, die jede sekunde überschrieben wird - wenn du jetzt nur mehr alle 20 sekunden statt alle 5 sekunden "wirklich" schreibst (also das was txg_sync macht ), dann schreibst du 4 mal weniger daten. das ganze funktioniert in echt natürlich komplizierter (sync vs. async writes, log devices, disk caches, ..).

Ich hab jetzt auch mal kurz nachgesehen wie es sich dabei mit dem Datenzuwachs verhält, und zwar obwohl die Total_LBAs_Written hochzählen blieb die Datenmenge gleich wenn ich alle gemounteten Volumes mittels "df" betrachte. Kann erst Abends wieder einen längeren Test machen über ein paar Stunden.

das spricht dafür das hier entweder daten immer wieder überschrieben werden oder es sich um metadaten handelt.

Gäbe es denn eine Möglichkeit mit einem ZFS Kommando mit zu schneiden was für Dateien geschrieben werden?

nicht für zfs, aber generell im linux kernel, das dazugehörige tool heißt fatrace und liefert welche dateien von welchem prozess geöffnet, gelesen, geschrieben und geschlossen werden (allerdings nicht wieviel daten).

 

[LnxBil]

Vielleicht auch relevant für diesen Thread hier, in dem ein wohl ähnlich gelagertes Problem beschrieben wird:

https://forum.proxmox.com/threads/proxmox-4-x-is-killing-my-ssds.29732/

 

[0815user]

Danke Fabian für den Hinweis auf den "fatrace", diesen Befehl kannte ich noch nicht. Ich konnte damit feststellen das folgende Dateien im 5sek. Takt geschrieben werden.
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764

Komisch finde ich aber das genau diese Dateinamen dort nicht existieren, sondern nur folgende Dateien sind vorhanden:
root@pve:~# ls -l /etc/pve/nodes/pve/
total 2
-rw-r----- 1 root www-data 83 Oct 21 16:31 lrm_status
-rw-r----- 1 root www-data 83 Sep 10 11:18 lrm_status.tmp.2731
drwxr-xr-x 2 root www-data 0 Aug 25 19:38 lxc
drwxr-xr-x 2 root www-data 0 Aug 25 19:38 openvz
drwx------ 2 root www-data 0 Aug 25 19:38 priv
-rw-r----- 1 root www-data 1675 Aug 25 19:38 pve-ssl.key
-rw-r----- 1 root www-data 1671 Aug 25 19:38 pve-ssl.pem
drwxr-xr-x 2 root www-data 0 Aug 25 19:38 qemu-server

Nachdem ich nun auch noch alle pve* Daemons gestoppt habe, und zum Schluss auch noch die Prozesse(pve-ha-lrm/pve-ha-crm) beendete, war in der fatrace Ausgabe nichts mehr zu sehen. Trotzdem wurden laut smartctl immer noch ca. 42MB innerhalb 15 Minuten Beobachtungszeitraum(hochgerechnet ca. 1GB pro Tag) geschrieben.
Es ist zwar nicht mehr so tragisch wie 11GB pro Tag bei inakiv laufenden PVE Prozessen, aber es ist meiner Meinung nach immer noch 1 GB zu viel für's NICHTS tun!

Danke auch an LnxBil, das erklärt dann wohl einiges(ich meine die Differenz von 1 auf 11GB pro Tag)!
Ich bin dann nur froh das meine SLOG SSD Platten laut eigener Beobachtung keiner solchen Abnutzung unterliegen, vermutlich einfach nur Glück gehabt.
Zusätzlich wollte aber auch eine Partition für ZFS L2ARC darauf anlegen, sowas muss ich mir leider nochmals gut überlegen ob das gut wäre für die Lebensdauer der SSDs?

 

[fabian]

Danke Fabian für den Hinweis auf den "fatrace", diesen Befehl kannte ich noch nicht. Ich konnte damit feststellen das folgende Dateien im 5sek. Takt geschrieben werden.
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764

Das sind Status Dateien vom ha-manager - allerdings sind das keine Dateien die auf ZFS liegen, da /etc/pve eine mit FUSE gemountete Datenbank ist (die eigentliche Datei dahinter liegt in /var/lib/pve-cluster/).

Komisch finde ich aber das genau diese Dateinamen dort nicht existieren, sondern nur folgende Dateien sind vorhanden:
root@pve:~# ls -l /etc/pve/nodes/pve/
total 2
-rw-r----- 1 root www-data 83 Oct 21 16:31 lrm_status
-rw-r----- 1 root www-data 83 Sep 10 11:18 lrm_status.tmp.2731
drwxr-xr-x 2 root www-data 0 Aug 25 19:38 lxc
drwxr-xr-x 2 root www-data 0 Aug 25 19:38 openvz
drwx------ 2 root www-data 0 Aug 25 19:38 priv
-rw-r----- 1 root www-data 1675 Aug 25 19:38 pve-ssl.key
-rw-r----- 1 root www-data 1671 Aug 25 19:38 pve-ssl.pem
drwxr-xr-x 2 root www-data 0 Aug 25 19:38 qemu-server

ja, die Dateien werden nicht direkt geschrieben, sondern es werden neue temp. Dateien angelegt und umbenannt.

Nachdem ich nun auch noch alle pve* Daemons gestoppt habe, und zum Schluss auch noch die Prozesse(pve-ha-lrm/pve-ha-crm) beendete, war in der fatrace Ausgabe nichts mehr zu sehen. Trotzdem wurden laut smartctl immer noch ca. 42MB innerhalb 15 Minuten Beobachtungszeitraum(hochgerechnet ca. 1GB pro Tag) geschrieben.
Es ist zwar nicht mehr so tragisch wie 11GB pro Tag bei inakiv laufenden PVE Prozessen, aber es ist meiner Meinung nach immer noch 1 GB zu viel für's NICHTS tun!

das wären dann nur mehr 48kb/s..

 

[0815user]

Hallo Fabian
Zuerst möchte ich mal mein Lob aussprechen für das was ihr vom Proxmox Team bisher zustande gebracht habt, ich finde es wirklich bemerkenswert.
Ein großes DANKE dafür!

Aber es hilft leider auch nicht sich die Zahlen/Werte etwas kleinere Einheiten um zu rechnen und zwar in kb/s, denn das macht sie auch nicht besser. Es sind in deinen Werten ausgedrückt 48kb/s, was trotzdem unnötige 48kb/s wären(nach meiner Berechnung wären es unnötige ~12kb/s), und in Wirklichkeit sind ja noch eher die 11GB/Tag(~133kb/s) das eigentliche Problem, und nicht das 1GB/Tag.
Ich würde mich sehr freuen darüber wenn sich das ProxmoxTeam dem Thema annimmt und verbessert, anstatt Energie zu verschwenden indem es die Werte schön rechnet. Leider bekommt man von einer solchen Vorgehensweise auch schnell den Eindruck das man damit nicht ernst genommen wird, und verliert das vertrauen in Proxmox. Auch ich habe hierfür einiges an Zeit investiert um es schriftlich hier auf zu bereiten, in dem Gedanken das Produkt ProxmoxVE damit voran zu bringen.

Falls derartige Mithilfe bei euch nicht gerne angenommen wird, dann lasse es mich bitte einfach wissen, und ich erspare mir/uns auch weitere Ausführungen dazu!

 

[fabian]

Hallo Fabian
Zuerst möchte ich mal mein Lob aussprechen für das was ihr vom Proxmox Team bisher zustande gebracht habt, ich finde es wirklich bemerkenswert.
Ein großes DANKE dafür!

Aber es hilft leider auch nicht sich die Zahlen/Werte etwas kleinere Einheiten um zu rechnen und zwar in kb/s, denn das macht sie auch nicht besser. Es sind in deinen Werten ausgedrückt 48kb/s, was trotzdem unnötige 48kb/s wären(nach meiner Berechnung wären es unnötige ~12kb/s), und in Wirklichkeit sind ja noch eher die 11GB/Tag(~133kb/s) das eigentliche Problem, und nicht das 1GB/Tag.
Ich würde mich sehr freuen darüber wenn sich das ProxmoxTeam dem Thema annimmt und verbessert, anstatt Energie zu verschwenden indem es die Werte schön rechnet. Leider bekommt man von einer solchen Vorgehensweise auch schnell den Eindruck das man damit nicht ernst genommen wird, und verliert das vertrauen in Proxmox. Auch ich habe hierfür einiges an Zeit investiert um es schriftlich hier auf zu bereiten, in dem Gedanken das Produkt ProxmoxVE damit voran zu bringen.

Falls derartige Mithilfe bei euch nicht gerne angenommen wird, dann lasse es mich bitte einfach wissen, und ich erspare mir/uns auch weitere Ausführungen dazu!

das umrechnen in kleinere einheiten war nicht als schönreden gedacht - bandbreite wird im allgemeinen pro sekunde und nicht pro tag angegeben, daher ist der vergleich mmn leichter.

wenn es konkrete hinweise gibt, woher unnötige (oder unnötig häufige) schreibzugriffe von PVE seite kommen, gehen wir dem natürlich gerne nach. in diesem fall war leider (bis jetzt) nichts konkrekt genug nachverfolgbar. vielleicht haben andere hier im forum noch ideen, wo du nachschauen könntest? ich komme hier auf meinem entwicklungssystem ohne laufende vms oder container laut "iostat" auf zwischen ~40kb/s und ~90kb/s

 

[0815user]

Also der konkrete Hinweis steht schon oben im Posting #6, aber hier nochmals aufgeschlüsselt.

Großes Übel:
Es passiert alle 5s ein Schreibvorgang auf "/etc/pve/nodes/pve/lrm_status.tmp.2764", dies wurde mittels "fatrace" festgestellt.
Dieser wiederkehrende Schreibvorgang bewirkt das ~10GB pro Tag geschrieben werden, wohlgemerkt wenn alle VMs heruntergefahren sind!
Sprich hier müsste mal der Hebel angesetzt werden, denn so scheint es für mich ist auch der Grund warum sich schon einige beklagen das deren SSDs drauf gehen(Stichwort: wear-out). Auch ich hatte ursprünglich vor SSDs ein zu setzten, was ich mir deshalb nun leider nicht tun kann/werde.
https://forum.proxmox.com/threads/proxmox-4-x-is-killing-my-ssds.29732/

Kleineres Übel(aber nicht unbedeutend):
Dies kann entweder etwas Kernel internes sein was mittels fatrace nicht angezeigt wird, oder meine Vermutung es handelt sich um ZFS interne Verwaltungsschreibzugriffe.
Dadurch wird ~1GB pro Tag auf die HDD geschrieben.

Ich habe auch schon überlegt um es vergleichend zu analysieren ein zweites Proxmox System auf zu setzten aber mit EXT4 anstelle von ZFS, aber leider fehlte mir die Zeit bis jetzt dafür. Vielleicht schaffe ich es die nächsten Tage mal, falls ja würde ich mich dazu wieder melden.

 

[fabian]

Großes Übel:
Es passiert alle 5s ein Schreibvorgang auf "/etc/pve/nodes/pve/lrm_status.tmp.2764", dies wurde mittels "fatrace" festgestellt.
Dieser wiederkehrende Schreibvorgang bewirkt das ~10GB pro Tag geschrieben werden, wohlgemerkt wenn alle VMs heruntergefahren sind!
Sprich hier müsste mal der Hebel angesetzt werden, denn so scheint es für mich ist auch der Grund warum sich schon einige beklagen das deren SSDs drauf gehen(Stichwort: wear-out). Auch ich hatte ursprünglich vor SSDs ein zu setzten, was ich mir deshalb nun leider nicht tun kann/werde.
https://forum.proxmox.com/threads/proxmox-4-x-is-killing-my-ssds.29732/

darauf hab ich schon geantwortet - alles was unter /etc/pve liegt liegt nicht direkt auf ZFS - /etc/pve ist eine per FUSE gemountete datenbank (sh. "man pmxcfs" für die technischen details). dh. alles an schreibzugriffen in dateien unter /etc/pve aufscheint, kannst du getrost ignorieren. was allerdings diesbezüglich relevant wäre, sind schreibzugriff auf "/var/lib/pve-cluster/" bzw. die darin enthaltenen dateien - dabei handelt es sich nämlich um die besagte datenbank.

Kleineres Übel(aber nicht unbedeutend):
Dies kann entweder etwas Kernel internes sein was mittels fatrace nicht angezeigt wird, oder meine Vermutung es handelt sich um ZFS interne Verwaltungsschreibzugriffe.
Dadurch wird ~1GB pro Tag auf die HDD geschrieben.

Ich habe auch schon überlegt um es vergleichend zu analysieren ein zweites Proxmox System auf zu setzten aber mit EXT4 anstelle von ZFS, aber leider fehlte mir die Zeit bis jetzt dafür. Vielleicht schaffe ich es die nächsten Tage mal, falls ja würde ich mich dazu wieder melden.

alles was potenziell licht ins dunkel bringt, ist gerne gesehen!

 

[0815user]

darauf hab ich schon geantwortet - alles was unter /etc/pve liegt liegt nicht direkt auf ZFS - /etc/pve ist eine per FUSE gemountete datenbank (sh. "man pmxcfs" für die technischen details). dh. alles an schreibzugriffen in dateien unter /etc/pve aufscheint, kannst du getrost ignorieren. was allerdings diesbezüglich relevant wäre, sind schreibzugriff auf "/var/lib/pve-cluster/" bzw. die darin enthaltenen dateien - dabei handelt es sich nämlich um die besagte datenbank.

Es wird genau nur diese eine Datei alle 5s geschrieben, sonst nichts(laut fatrace)!
Warum sollte ich es ignorieren, wenn nachdem diese geschrieben wurde und NUR diese Datei, dann der Zähler der Festplatte(Total LBAs written) hochzählt.
Also schließe ich daraus das genau diese Datei dafür verantwortlich ist, und keine andere!

 

[fabian]

Es wird genau nur diese eine Datei alle 5s geschrieben, sonst nichts(laut fatrace)!
Warum sollte ich es ignorieren, wenn nachdem diese geschrieben wurde und NUR diese Datei, dann der Zähler der Festplatte(Total LBAs written) hochzählt.
Also schließe ich daraus das genau diese Datei dafür verantwortlich ist, und keine andere!

noch einmal:

diese datei ist keine datei auf der platte, sondern teil einer per FUSE gemounteten datenbank. bist du dir sicher dass du keine schreibzugriffe auf "/var/lib/pve-cluster/config.db-wal" siehst? die sollten deutlich öfter vorkommen als das alle 5 sekunden neuschreiben der lrm_status datei!

 

[0815user]

Nein, die ".../config.db-wal" habe ich bis jetzt noch gar nie gesehen und auch keine anderen files! (habe bereits mehrfach für ein paar Minuten fatrace laufen lassen.
Aber vielleicht glaubst du mir wenn ich dir etwas aus dem PuTTY Fenster kopiere:

root@pve:~# time fatrace
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): W /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): W /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): W /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): W /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): O /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): W /etc/pve/nodes/pve/lrm_status.tmp.2764
pve-ha-lrm(2764): CW /etc/pve/nodes/pve/lrm_status.tmp.2764
^C
real    2m4.077s
user    0m0.000s
sys     0m0.004s
root@pve:~#

Habe auch time mit laufen lassen um zu zeigen das es sich um 2 Minuten 4 Sekunden handelt, und diese Zugriffe passieren regelmäßig genau alle 5 Sekunden!

 

[fabian]

das sieht sehr seltsam aus.. eventuell hast du beim versuch alles unnötige abzudrehen "zu viel" abgedreht? fatrace sollte auf jeden fall deutlich mehr als nur den pve-ha-lrm prozess anzeigen

um ein bisschen zum thema zurückzukehren: auch wenn ich nach wie vor der meinung bin, dass das von dir beschriebene verhalten nicht wirklich schlimm ist (auch brauchbare SSDs sollten das problemlos verkraften!), zumal ein PVE node mit VMs/containern drauf ein vielfaches an I/O erzeugt, gibt es noch eine "schraube" an der du drehen kannst. die von mir genannte datenbank liegt auf ZFS (wie gesagt, in /var/lib/pve-cluster), und wie alle datenbanken schreibt diese oft und in kleinen mengen. zfs schreibt standardmäßig in (bis zu) 128k blöcken, was bei vielen kleinen schreibzugriffen zu unnötig viel schreiben auf der platte führt. wenn du für den ordner /var/lib/pve-cluster ein eigenes zfs dataset mit recordsize 1024 anlegst, könnte dass das schreibaufkommen reduzieren (du musst dafür allerdings erst alle PVE services stoppen, den ordner umbenennen, das dataset anlegen und mounten und die alten dateien hinüberkopieren).

bitte nur auf testsystemen / bei vorhandenem backup machen, da die datenbank den kompletten inhalt von /etc/pve darstellt - wenn die kaputt ist, ist viel kaputt!

 

[0815user]

Ja, da stimme ich dir zu, es sieht seltsam aus, und nein ich habe nicht zu viel abgedreht. Genauer genommen hatte ich während der fatrace letztes mal gar nichts abgedreht!
Sogar 2 VMs(1x Windows Server + 1x Debian) liefen währenddessen darauf.

Das scheint leider ein weiteres Problem zu sein, das "fatrace" ohne Parameter aufgerufen nicht zu gebrauchen ist wenn man ZFS verwendet.
Wie wir damit sehen konnten liefert es keine brauchbare Ausgabe, ich habe heute sogar ein Datei erzeugt/geschrieben, welchen es mir nicht anzeigte.

Zur Info, obiges hab ich jetzt mit 2 frisch installierten Proxmox VE 4.3 getestet, eine mit ZFS und die andere mit ext4 Dateisystem.
Bei ZFS funktioniert fatrace nicht wie es sollte, denn bei einer reinen ext4 Installation zeigt es alle Dateizugriffe an wie man es sich vorstellt!
Danach habe ich "fatrace -c" auf ZFS verwendet, welches aber leider nur das aktuelle Dateisystem überwacht(in meinem Fall das root-fs), das bringt dann einiges mehr ans Licht. Muss aber aus Zeitgründen diese Ausgabe ein anderes mal durchsehen, mal sehen ob ich schlau daraus werde.

 

[morph027]

Ich liefer das mal nach:

pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pveproxy worker(40259): W /var/log/pveproxy/access.log
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pmxcfs(8374): W /var/lib/pve-cluster/config.db-wal
pveproxy worker(40259): W /var/log/pveproxy/access.log

Ich teste das mit dem Extra Dataset mal schnell auf einem meiner Lab Server...

 

[morph027]

Das geht soweit erst mal gut...

systemctl stop {pve-manager,pve-cluster,pve-firewall,pve-ha-crm,pve-ha-lrm,pvebanner,pvefw-logger,pvenetcommit,pveproxy,pvestatd,pvedaemon}
mv /var/lib/pve-cluster /var/lib/pve-cluster-backup
zfs create -o recordsize=1024 -o mountpoint=/var/lib/pve-cluster rpool/pve-cluster-database
cp /var/lib/pve-cluster-backup/* /var/lib/pve-cluster/
systemctl start {pve-manager,pve-cluster,pve-firewall,pve-ha-crm,pve-ha-lrm,pvebanner,pvefw-logger,pvenetcommit,pveproxy,pvestatd,pvedaemon}

Ich beobachte mal das Ding im Leerlauf...

Stand jetzt:

------------------------------
 SSD Status:  /dev/sda
------------------------------
 On time:  12,191 hr
------------------------------
 Data written:
  MB: 27,740,352.349
  GB: 27,090.187
  TB: 26.455
------------------------------
 Mean write rate:
  MB/hr: 2,275.478
------------------------------
 Drive health: 96 %
------------------------------

 

[morph027]

Update:

------------------------------
 SSD Status:  /dev/sda
------------------------------
 On time:  12,200 hr
------------------------------
 Data written:
  MB: 27,745,597.548
  GB: 27,095.310
  TB: 26.460
------------------------------
 Mean write rate:
  MB/hr: 2,274.229
------------------------------
 Drive health: 96 %
------------------------------

 

[0815user]

Danke morph027, bei mir sieht es ähnlich aus, nur die access.log habe ich nicht.(vermutlich weil ich auf die Webseite nicht zugreife während ich mit "fatrace -c" mit schaue.)

Es handelt sich um eine frisch installierte Maschine ohne VMs(Ausgabe gefiltert auf nur Schreibzugriffe):

pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pvestatd(2090): CWO /var/log/pve/tasks/.active.lock
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pvestatd(2090): CWO /var/log/pve/tasks/.active.lock
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pvestatd(2090): CWO /var/log/pve/tasks/.active.lock
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal
pmxcfs(1989): W /var/lib/pve-cluster/config.db-wal