NEWS
ioBroker sehr hohe Diskwrites in Proxmox
-
@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@jleg das ist für States.jsonl aber egal weil das nur der Controller Prozess schreibt …
..der dann aber in der htop-"Hitliste" oben entsprechend auftauchen müsste, oder nicht?
-
@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@jleg das ist für States.jsonl aber egal weil das nur der Controller Prozess schreibt …
..der dann aber in der htop-"Hitliste" oben entsprechend auftauchen müsste, oder nicht?
@jleg Richtig! Und das habe ich hier auch schon vor zwei Tagen so geschrieben. :wink:
-
@dr-bakterius interessant ist der zweite wert. Das sind „state changes“. der erste ist nur das was der Adapter von anderen subscribed hat. Und ja Admin bekommt halt am Ende viele Daten aber schreibt selbst wenig.
Du musst die suchen die alle zweite Zahl viel haben.
@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Du musst die suchen die alle zweite Zahl viel haben.
Danke für die Erklärung! :+1:
So sehen alle meine Instanzen aus:
So 900-1000 Ausgabeereignisse gesamt. Über welchen Zeitraum gesehen eigentlich? Ist das außergewöhnlich viel? Wenn ich die drei Instanzen mit den höchsten Werten beende, reduzieren sich die Ausgabeereignisse um knapp 50%. Und auch das Neuschreiben der states.jsonl erfolgt dann nur noch etwa halb so oft. Das ist soweit nachvollziehbar.
Was ich nicht nachvollziehen kann, dass das Volumen dann immer noch etwa 50x so hoch ist wie noch im Juli! Wurde da sicher nichts bei der Behandlung von jsonl geändert? Wird jetzt häufiger komprimiert?
-
@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Du musst die suchen die alle zweite Zahl viel haben.
Danke für die Erklärung! :+1:
So sehen alle meine Instanzen aus:
So 900-1000 Ausgabeereignisse gesamt. Über welchen Zeitraum gesehen eigentlich? Ist das außergewöhnlich viel? Wenn ich die drei Instanzen mit den höchsten Werten beende, reduzieren sich die Ausgabeereignisse um knapp 50%. Und auch das Neuschreiben der states.jsonl erfolgt dann nur noch etwa halb so oft. Das ist soweit nachvollziehbar.
Was ich nicht nachvollziehen kann, dass das Volumen dann immer noch etwa 50x so hoch ist wie noch im Juli! Wurde da sicher nichts bei der Behandlung von jsonl geändert? Wird jetzt häufiger komprimiert?
@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Über welchen Zeitraum gesehen eigentlich?
15s ist das Messinterval und auch aktualisierungsinterval. AN sich wird nicht häufiger komprimiert wenn ich recht entsinne @AlCalzone ... oder fällt Dir was ein?
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Über welchen Zeitraum gesehen eigentlich?
15s ist das Messinterval und auch aktualisierungsinterval. AN sich wird nicht häufiger komprimiert wenn ich recht entsinne @AlCalzone ... oder fällt Dir was ein?
@apollon77 @Dr-Bakterius Geändert hat sich da nix.
Die jsonl-DB ist so voreingestellt, dass bei jeder Verdopplung der Datei (bei mind. 1000 Zeilen) komprimiert wird, d.h. alles neu geschrieben. In der Regel sollte das mit der Zeit immer seltener passieren.
Wenn deine Ereignisse viele Duplikate enthalten könnte ich mir vorstellen, dass recht häufig komprimiert wird, ohne dass sich an der Netto-Größe der Datei viel ändert und du ständig in diese Bedingung reinläufst.Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@apollon77 @Dr-Bakterius Geändert hat sich da nix.
Die jsonl-DB ist so voreingestellt, dass bei jeder Verdopplung der Datei (bei mind. 1000 Zeilen) komprimiert wird, d.h. alles neu geschrieben. In der Regel sollte das mit der Zeit immer seltener passieren.
Wenn deine Ereignisse viele Duplikate enthalten könnte ich mir vorstellen, dass recht häufig komprimiert wird, ohne dass sich an der Netto-Größe der Datei viel ändert und du ständig in diese Bedingung reinläufst.@alcalzone sagte in ioBroker sehr hohe Diskwrites in Proxmox:
In der Regel sollte das mit der Zeit immer seltener passieren.
Wie das? Die Adapter schreiben Werte in die Datenpunkte bzw. aktualisieren diese. Dabei wird der Wert (plus Zeitstempel?) in die states.jsonl geschrieben, oder? Das wird doch nicht weniger mit der Zeit.
Gut, ich habe ein oder zwei Steckdosen in den sonoff-Adapter hinzugefügt, sonst aber nur Updates der Adapter gemacht. Also wieso dann plötzlich die schnelle Verdoppelung der Dateigröße? Wenn die Diskwrites faktisch alleine von dieser Datei abhängen, dann hat sich das von etwa 5 Stunden auf 3 Minuten reduziert! Fällt dir etwas auf bei der Anzahl der Ausgabeereignisse (in meinem Bild oben)?
Das einzige was ich mir noch vorstellen könnte: Proxmox hat das bisher völlig falsch angezeigt (gab auch da Updates zu diesem Zeitpunkt). Kann ich mir aber eigentlich nicht vorstellen...
-
@alcalzone sagte in ioBroker sehr hohe Diskwrites in Proxmox:
In der Regel sollte das mit der Zeit immer seltener passieren.
Wie das? Die Adapter schreiben Werte in die Datenpunkte bzw. aktualisieren diese. Dabei wird der Wert (plus Zeitstempel?) in die states.jsonl geschrieben, oder? Das wird doch nicht weniger mit der Zeit.
Gut, ich habe ein oder zwei Steckdosen in den sonoff-Adapter hinzugefügt, sonst aber nur Updates der Adapter gemacht. Also wieso dann plötzlich die schnelle Verdoppelung der Dateigröße? Wenn die Diskwrites faktisch alleine von dieser Datei abhängen, dann hat sich das von etwa 5 Stunden auf 3 Minuten reduziert! Fällt dir etwas auf bei der Anzahl der Ausgabeereignisse (in meinem Bild oben)?
Das einzige was ich mir noch vorstellen könnte: Proxmox hat das bisher völlig falsch angezeigt (gab auch da Updates zu diesem Zeitpunkt). Kann ich mir aber eigentlich nicht vorstellen...
@dr-bakterius Die Datei ist erstmal append-only bis zum erneuten Schreiben nach Erreichen einer Schwelle. Jede Änderung eines States entspricht einer neuen Zeile, die angefügt wird. Wenn durch dieses Anfügen die Datei auf die doppelte Länge des letzten Kompressionsvorgangs angewachsen ist, wird ein neuer ausgelöst. Je mehr States du hast, desto länger dauert es, bis sich die Größe verdoppelt hat, weil die Baseline auch höher ist.
Wie viele States hast du denn insgesamt?
Und bist du ganz sicher, dass es an
states.jsonlliegt und nichtobjects.jsonl? Nicht dass einer der Adapter seit dem Update ständig seine Objekte neu schreibt. Da ist die Schwelle deutlich geringer und die Datenmenge wesentlich höher.Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@dr-bakterius Die Datei ist erstmal append-only bis zum erneuten Schreiben nach Erreichen einer Schwelle. Jede Änderung eines States entspricht einer neuen Zeile, die angefügt wird. Wenn durch dieses Anfügen die Datei auf die doppelte Länge des letzten Kompressionsvorgangs angewachsen ist, wird ein neuer ausgelöst. Je mehr States du hast, desto länger dauert es, bis sich die Größe verdoppelt hat, weil die Baseline auch höher ist.
Wie viele States hast du denn insgesamt?
Und bist du ganz sicher, dass es an
states.jsonlliegt und nichtobjects.jsonl? Nicht dass einer der Adapter seit dem Update ständig seine Objekte neu schreibt. Da ist die Schwelle deutlich geringer und die Datenmenge wesentlich höher.@alcalzone Ich habe jetzt mal zum Testen wieder auf file|file umgestellt. Da wurden 11.836 states und 10.960 objects konvertiert. Danach den Container neu gestartet und 10 Minuten beobachtet. In diesen 10 Minuten wurden deutlich weniger Schreibzugriffe lt. Proxmox durchgeführt.
Dann wieder zurück auf jsonl|jsonl und ich bin wieder da wo ich vorher war.
In den letzten 15 Minuten wurde die states.jsonl 5x neu geschrieben weil sich die Größe verdoppelt hatte. Die objects.jsonl ist anfangs um 15% angewachsen und bleibt seit 10 Minuten stabil auf ihrer Größe. Ich glaube also nicht, dass ein Adapter ständig seine Objekte neu schreibt.
Anfang des Jahres waren die Schreibzugriffe exorbitant höher als ich noch auf file|file war. Bei redis gingen diese deutlich zurück und dann mit jsonl sanken sie faktisch auf null. Und seit ende Juli sind sie plötzlich so hoch - höher als bei file! Ich verstehe es nicht...
-
Hmmm, ich meine mich zu erinnern, dass ich damals bei der Umstellung auf JSONL irgendwas in einer Datei angepasst hab dafür...aber das wars auch schon, woran ich mich meine zu erinnern...man konnte doch das Verhalten bei JSONL selber etwas manipulieren/seinen Bedürfnissen anpassen? Ggf wurde da was überschrieben?
-
@alcalzone Ich habe jetzt mal zum Testen wieder auf file|file umgestellt. Da wurden 11.836 states und 10.960 objects konvertiert. Danach den Container neu gestartet und 10 Minuten beobachtet. In diesen 10 Minuten wurden deutlich weniger Schreibzugriffe lt. Proxmox durchgeführt.
Dann wieder zurück auf jsonl|jsonl und ich bin wieder da wo ich vorher war.
In den letzten 15 Minuten wurde die states.jsonl 5x neu geschrieben weil sich die Größe verdoppelt hatte. Die objects.jsonl ist anfangs um 15% angewachsen und bleibt seit 10 Minuten stabil auf ihrer Größe. Ich glaube also nicht, dass ein Adapter ständig seine Objekte neu schreibt.
Anfang des Jahres waren die Schreibzugriffe exorbitant höher als ich noch auf file|file war. Bei redis gingen diese deutlich zurück und dann mit jsonl sanken sie faktisch auf null. Und seit ende Juli sind sie plötzlich so hoch - höher als bei file! Ich verstehe es nicht...
@dr-bakterius Naja Du hast zwei Adapter die recht viel ausgehende States hatten ... ggf hat sich ja da was geändert ... bzw @AlCalzone hatten wir nicht den Bug das ggf gar nicht compressed wurde und deswegen das eine setting im code hinzugefügt? ;-)
-
@alcalzone Ich habe jetzt mal zum Testen wieder auf file|file umgestellt. Da wurden 11.836 states und 10.960 objects konvertiert. Danach den Container neu gestartet und 10 Minuten beobachtet. In diesen 10 Minuten wurden deutlich weniger Schreibzugriffe lt. Proxmox durchgeführt.
Dann wieder zurück auf jsonl|jsonl und ich bin wieder da wo ich vorher war.
In den letzten 15 Minuten wurde die states.jsonl 5x neu geschrieben weil sich die Größe verdoppelt hatte. Die objects.jsonl ist anfangs um 15% angewachsen und bleibt seit 10 Minuten stabil auf ihrer Größe. Ich glaube also nicht, dass ein Adapter ständig seine Objekte neu schreibt.
Anfang des Jahres waren die Schreibzugriffe exorbitant höher als ich noch auf file|file war. Bei redis gingen diese deutlich zurück und dann mit jsonl sanken sie faktisch auf null. Und seit ende Juli sind sie plötzlich so hoch - höher als bei file! Ich verstehe es nicht...
@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:
11.836 states
Lass mal rechnen.
1000 Ausgabeereignisse alle 15 Sekunden, macht etwa 12.000 Schreibvorgänge in 3 Minuten.
Das deckt sich ziemlich genau mit deiner Beobachtung, dass alle 3 Minuten komprimiert wird, weil sich dann die DB-Größe verdoppelt hat.hatten wir nicht den Bug das ggf gar nicht compressed wurde und deswegen das eine setting im code hinzugefügt?
Möglich. Ich weiß nicht genau, welche Version @Dr-Bakterius vorher im Einsatz hatte.
Anyways - hier kann man sicher noch Feintuning betreiben, genau dafür machen wir solche Tests ja. An sich ist die Auto-Kompression dafür gedacht, dass die Dateien größentechnisch nicht komplett aus dem Ruder laufen und das Laden etwas schneller geht.
Für Objects haben wir Größenfaktor 2, mind. 1000 Zeilen als Bedingung für Neu-Schreiben. Die 1000 sind hier die Anzahl der teils redundanten Zeilen in der DB, nicht die einzigartigen Objekte.
Für States ist die Einstellung aktuell identisch. Ich hab nur etwa halb so viele States und meinestates.jsonldümpelt irgendwo zwischen 2-3 MB herum. Also Größentechnisch nix wildes.Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)Das wird dafür sorgen, dass die DBs deutlich seltener komprimiert werden - bei kleineren Installationen so gut wie nie. Ist jetzt vermutlich nicht schlimm, aber ggf. muss man es dann zeitgesteuert ab und an machen.
Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:
11.836 states
Lass mal rechnen.
1000 Ausgabeereignisse alle 15 Sekunden, macht etwa 12.000 Schreibvorgänge in 3 Minuten.
Das deckt sich ziemlich genau mit deiner Beobachtung, dass alle 3 Minuten komprimiert wird, weil sich dann die DB-Größe verdoppelt hat.hatten wir nicht den Bug das ggf gar nicht compressed wurde und deswegen das eine setting im code hinzugefügt?
Möglich. Ich weiß nicht genau, welche Version @Dr-Bakterius vorher im Einsatz hatte.
Anyways - hier kann man sicher noch Feintuning betreiben, genau dafür machen wir solche Tests ja. An sich ist die Auto-Kompression dafür gedacht, dass die Dateien größentechnisch nicht komplett aus dem Ruder laufen und das Laden etwas schneller geht.
Für Objects haben wir Größenfaktor 2, mind. 1000 Zeilen als Bedingung für Neu-Schreiben. Die 1000 sind hier die Anzahl der teils redundanten Zeilen in der DB, nicht die einzigartigen Objekte.
Für States ist die Einstellung aktuell identisch. Ich hab nur etwa halb so viele States und meinestates.jsonldümpelt irgendwo zwischen 2-3 MB herum. Also Größentechnisch nix wildes.Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)Das wird dafür sorgen, dass die DBs deutlich seltener komprimiert werden - bei kleineren Installationen so gut wie nie. Ist jetzt vermutlich nicht schlimm, aber ggf. muss man es dann zeitgesteuert ab und an machen.
@alcalzone sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)Macht sinn und ja States Faktor 10
@Dr-Bakterius machst du uns bitte im js-controller ein issue dazu?
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@alcalzone sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)Macht sinn und ja States Faktor 10
@Dr-Bakterius machst du uns bitte im js-controller ein issue dazu?
@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
machst du uns bitte im js-controller ein issue dazu?
Erledigt. (https://github.com/ioBroker/ioBroker.js-controller/issues/1437)
-
@alcalzone sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)Macht sinn und ja States Faktor 10
@Dr-Bakterius machst du uns bitte im js-controller ein issue dazu?
@apollon77 @AlCalzone vllt willst Du hier sagen wie man das jetzt schon in der iobroker.json konfigurieren kann?
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@dr-bakterius interessant ist der zweite wert. Das sind „state changes“. der erste ist nur das was der Adapter von anderen subscribed hat. Und ja Admin bekommt halt am Ende viele Daten aber schreibt selbst wenig.
Du musst die suchen die alle zweite Zahl viel haben.
@apollon77 Hallo, das ist jetzt vlt etwas off-topic aber ich lese diesen thread mit und bei deiner Antwort zu den "state changes" bin ich etwas stutzig geworden.
Mein System (proxmox container mit debian 10) läuft stabil aber ich habe beim Sonoff Adapter sehr hohe Werte:
Muss ich mir da Sorgen machen oder ist das eben so, wenn man viele (ca 70) Geräte an dem Adapter hat. die auch viele Status-Updates senden?
-
@apollon77 @AlCalzone vllt willst Du hier sagen wie man das jetzt schon in der iobroker.json konfigurieren kann?
-
@apollon77 Hallo, das ist jetzt vlt etwas off-topic aber ich lese diesen thread mit und bei deiner Antwort zu den "state changes" bin ich etwas stutzig geworden.
Mein System (proxmox container mit debian 10) läuft stabil aber ich habe beim Sonoff Adapter sehr hohe Werte:
Muss ich mir da Sorgen machen oder ist das eben so, wenn man viele (ca 70) Geräte an dem Adapter hat. die auch viele Status-Updates senden?
@amg_666 naja hast dir die Frage an sich selbst beantwortet. Wenn es viele state changes gibt dann willst du das ja haben also …. Viel state changes der Geräte die beim Adapter ankommen ergeben (logischerweise) auch die gleiche Anzahl States changes in iobroker. ;-))
Am Ende ist das doch auch nicht schlimm und genau das was du willst.
-
@apollon77 @AlCalzone vllt willst Du hier sagen wie man das jetzt schon in der iobroker.json konfigurieren kann?
@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@AlCalzone vllt willst Du hier sagen wie man das jetzt schon in der iobroker.json konfigurieren kann?
Wäre genau meine nächste Frage gewesen. ;-)
-
@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@AlCalzone vllt willst Du hier sagen wie man das jetzt schon in der iobroker.json konfigurieren kann?
Wäre genau meine nächste Frage gewesen. ;-)
-
Hallo Zusammen,
vorab erstmal vielen Dank für diese ganzen Infos die man hier im Forum findet.
Im Bezug auf das Thema Diskwrites habe ich folgendes Problem:
Ich habe den ioBroker erstmal auf *.jsonl laufen lassen.
Dabei habe ich festgestellt, dass mehr als 30GB pro Tag auf die SSD geschrieben wurden.
Ich habe dann testweise man auf Redis umgestellt und habe jetzt 1GB/h also 24GB pro Tag.
Das finde ich einfach zu viel. Es laufen nur 20 Adapter. Ich kann einfach nicht nachvollziehen wieso so viele Daten geschrieben werden.Vielleicht kann mir jemand helfen? Wenn ja, sagt mir bitte, welche Infos ihr von meinem System benötigt.
Vielen Dank
320
Online32.6k
Users82.2k
Topics1.3m
Posts