ioBroker sehr hohe Diskwrites in Proxmox
-
@apollon77 Danke für den Hinweis.
Allgemein.
Vorab. Ich bewundere das Engagement von den vielen ehrenamtlichen Entwicklern und die tolle Leistung. Ich liebe iobroker immer noch, aber
die Komplexität von iobroker ist viel zu groß.Es ist sehr bedauerlich, dass der Nutzer sich mit dieser Art von "Eingeweide"- Konfiguration überhaupt beschäftigen muss
Mich hat das Thema fast 2 h gekostet, bis ich den ganzen "Quatsch" mit der Redis Config für diese Spezialität so halbwegs verstanden und geändert hatte.
Außerdem hätte ich nicht Promox genutzt, dann wäre mir die SSD- Schreiberei gar nicht aufgefallen und z.B. auf einem Raspberry wäre mir die SD Karte nach einem halben Jahr abgeraucht. Ich hätte mich gewundert und beim nächsten Ausfall wäre ich vermutlich zu Amazon oder Google gewechselt und hätte zähneknirschend auf etliche Funktionen verzichtet.
Klar, wenn ich hauptberuflich Systemadministrator wäre, dann würde ich darüber nur schmunzeln und die Sache wäre in einer Minute erledigt.
So muss ich ein Know How aufbauen, was ich einmal in meinem Leben benötige, in einem Monat ohnehin wieder vergessen haben und bei der nächsten ioBroker Installation in 2 Jahren wiederholt sich dieser Prozess wieder. Das killt jegliche Produktivität.
So wird ioBroker leider nie Mainstream und nur nutzbar für Linux Admins und Nerds. Die Folge, die drei Gatekeeper, Apple, Google und Amazon werden sich den Markt unter sich aufteilen, mit schlechten Ansätzen dominieren und die IoT- Hersteller mit Lizenzen zu teuren Produkte zwingen.
Das ist sehr schade und eine verpasste Chance.
@marty56 äääähhhmm. Das - vor allem in Kombi mit redis - kapiere ich jetzt nicht.
Wer bitte sagt das du redis nutzen sollst? Nur weil es geht?? Der Standard ist die file dB und die ist out of the Box da und ist für 99,x Prozent der User und use cases das sinnvolle.
Und mit der musst du dich um nichts kümmern.Redis ist für Seeeehr speziellere Fälle. Gibt sogar einen forum Thread zu redis und wann es Sinn macht und was es zu beachten gibt.
Von daher muss ich das Feedback leider in der form entschieden zurückweisen. Vllt sind wir eher an dem Punkt das ioBroker schon an einigen Stellen Zuviel kann und dann „spielekinder“ ( ;-) ) Dinge tun weil sie halt gehen und sie denken es macht Sinn. Aber ehrlich: dann gilt durchaus „selber schuld“.
-
@marty56 äääähhhmm. Das - vor allem in Kombi mit redis - kapiere ich jetzt nicht.
Wer bitte sagt das du redis nutzen sollst? Nur weil es geht?? Der Standard ist die file dB und die ist out of the Box da und ist für 99,x Prozent der User und use cases das sinnvolle.
Und mit der musst du dich um nichts kümmern.Redis ist für Seeeehr speziellere Fälle. Gibt sogar einen forum Thread zu redis und wann es Sinn macht und was es zu beachten gibt.
Von daher muss ich das Feedback leider in der form entschieden zurückweisen. Vllt sind wir eher an dem Punkt das ioBroker schon an einigen Stellen Zuviel kann und dann „spielekinder“ ( ;-) ) Dinge tun weil sie halt gehen und sie denken es macht Sinn. Aber ehrlich: dann gilt durchaus „selber schuld“.
@apollon77
Erstmal ich wollte niemanden verletzten. Falls ich das doch getan habe, bitte ich um Entschuldigung.Ich habe redis nur aus einem Grund ausgewählt, weil ich gehofft habe, mit einer In-Memory DB das Wear-Out meiner SSD zu verlangsamen. Defakto habe ich - durch meine "nachlässige" Konfiguration - genau das Gegenteil erreicht.
Klar mein Fehler. Aber das war nicht mein Punkt. Mein Punkt ist, dass Otto Normaluser sich mit solchen Sachen überhaupt herumschlagen muss. Und wenn er das nicht macht, zerschießt er sich sein System nach kurzer Zeit.Der file-basierte Ansatz hat ja genau dasselbe Problem. Hier muss ich in irgendwelchen Json Files neue Felder einfügen, die das Schreiben reduzieren. Meines Wissen gibt es dafür auch kein selbsterklärendes UI.
Die Hürde ist ähnlich hoch, wie bei Redis.HW:NUC (16 GB Ram)
OS: Debian Bullseye, Promox V7, node v16.x npm 8.19.3 -
@apollon77
Erstmal ich wollte niemanden verletzten. Falls ich das doch getan habe, bitte ich um Entschuldigung.Ich habe redis nur aus einem Grund ausgewählt, weil ich gehofft habe, mit einer In-Memory DB das Wear-Out meiner SSD zu verlangsamen. Defakto habe ich - durch meine "nachlässige" Konfiguration - genau das Gegenteil erreicht.
Klar mein Fehler. Aber das war nicht mein Punkt. Mein Punkt ist, dass Otto Normaluser sich mit solchen Sachen überhaupt herumschlagen muss. Und wenn er das nicht macht, zerschießt er sich sein System nach kurzer Zeit.Der file-basierte Ansatz hat ja genau dasselbe Problem. Hier muss ich in irgendwelchen Json Files neue Felder einfügen, die das Schreiben reduzieren. Meines Wissen gibt es dafür auch kein selbsterklärendes UI.
Die Hürde ist ähnlich hoch, wie bei Redis.@marty56 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Der file-basierte Ansatz hat ja genau dasselbe Problem. Hier muss ich in irgendwelchen Json Files neue Felder einfügen, die das Schreiben reduzieren. Meines Wissen gibt es dafür auch kein selbsterklärendes UI.
Die Hürde ist ähnlich hoch, wie bei Redis.Nö, mit Admin 5 kannst du das besagte JSON via UI modifizieren.
-
@apollon77
Erstmal ich wollte niemanden verletzten. Falls ich das doch getan habe, bitte ich um Entschuldigung.Ich habe redis nur aus einem Grund ausgewählt, weil ich gehofft habe, mit einer In-Memory DB das Wear-Out meiner SSD zu verlangsamen. Defakto habe ich - durch meine "nachlässige" Konfiguration - genau das Gegenteil erreicht.
Klar mein Fehler. Aber das war nicht mein Punkt. Mein Punkt ist, dass Otto Normaluser sich mit solchen Sachen überhaupt herumschlagen muss. Und wenn er das nicht macht, zerschießt er sich sein System nach kurzer Zeit.Der file-basierte Ansatz hat ja genau dasselbe Problem. Hier muss ich in irgendwelchen Json Files neue Felder einfügen, die das Schreiben reduzieren. Meines Wissen gibt es dafür auch kein selbsterklärendes UI.
Die Hürde ist ähnlich hoch, wie bei Redis. -
@apollon77
Erstmal ich wollte niemanden verletzten. Falls ich das doch getan habe, bitte ich um Entschuldigung.Ich habe redis nur aus einem Grund ausgewählt, weil ich gehofft habe, mit einer In-Memory DB das Wear-Out meiner SSD zu verlangsamen. Defakto habe ich - durch meine "nachlässige" Konfiguration - genau das Gegenteil erreicht.
Klar mein Fehler. Aber das war nicht mein Punkt. Mein Punkt ist, dass Otto Normaluser sich mit solchen Sachen überhaupt herumschlagen muss. Und wenn er das nicht macht, zerschießt er sich sein System nach kurzer Zeit.Der file-basierte Ansatz hat ja genau dasselbe Problem. Hier muss ich in irgendwelchen Json Files neue Felder einfügen, die das Schreiben reduzieren. Meines Wissen gibt es dafür auch kein selbsterklärendes UI.
Die Hürde ist ähnlich hoch, wie bei Redis.@marty56 an sich muss auch mit file dB niemand an dem Wert etwa ändern. Mit js Controller 3.2/3 haben wir hier optimiert. Und für Controller 3.4 stellen wir Vorauss auf jsonl um was dann nochmals optimiert.
Am Ende ist die Standardeinstellung ein Kompromiss zwischen wrong Datenverlust im Crash Fall und nicht Zuviel Schreiblast. Also auch wer an dem Wert rumdreht (und das „muss“ keiner) sollte verstehen was er da tut weil es Konsequenzen haben kann.
Von daher sieh es doch mal so: vllt gibt es ja einen Grund das bestimmte Einstellungen explizit nicht so einfach änderbar sind. ;-))
-
@marty56 an sich muss auch mit file dB niemand an dem Wert etwa ändern. Mit js Controller 3.2/3 haben wir hier optimiert. Und für Controller 3.4 stellen wir Vorauss auf jsonl um was dann nochmals optimiert.
Am Ende ist die Standardeinstellung ein Kompromiss zwischen wrong Datenverlust im Crash Fall und nicht Zuviel Schreiblast. Also auch wer an dem Wert rumdreht (und das „muss“ keiner) sollte verstehen was er da tut weil es Konsequenzen haben kann.
Von daher sieh es doch mal so: vllt gibt es ja einen Grund das bestimmte Einstellungen explizit nicht so einfach änderbar sind. ;-))
@apollon77 Ok. Dann freue ich mich auf die Updates.
Nachdem ich redis etwas wenig schreiben lasse, ist mein Disk IO auf ca. 500 KB pro Stunde gesunken.
Diese 500 KB kann ich fast vollständig der SQLite3 DB zuordnen. Wenn ich die ausschalte, dann liegt das Disk IO bei 0 Byte (was auch schon wieder komisch ist, weil das Log ja noch geschrieben wird).
Kann ich statt SQLite3 eine andere Datenbank nehmen, die so ähnlich wie redis jetzt bei mir nur einmal pro Stunde schreibt?
HW:NUC (16 GB Ram)
OS: Debian Bullseye, Promox V7, node v16.x npm 8.19.3 -
@apollon77 Ok. Dann freue ich mich auf die Updates.
Nachdem ich redis etwas wenig schreiben lasse, ist mein Disk IO auf ca. 500 KB pro Stunde gesunken.
Diese 500 KB kann ich fast vollständig der SQLite3 DB zuordnen. Wenn ich die ausschalte, dann liegt das Disk IO bei 0 Byte (was auch schon wieder komisch ist, weil das Log ja noch geschrieben wird).
Kann ich statt SQLite3 eine andere Datenbank nehmen, die so ähnlich wie redis jetzt bei mir nur einmal pro Stunde schreibt?
-
@marty56 sagte: wie redis jetzt bei mir nur einmal pro Stunde schreibt?
Hast Du eine USV? Falls nicht, ist eine Stunde sehr lang.
-
@marty56
ich habe eher den Eindruck, dass Du dich aufgrund eines Wertes der dir aufgefallen ist (Wearout) künstlich verrückt machst, ohne dass irgend etwas los ist.[EDIT]
auflschlussreich https://forum.iobroker.net/post/566162 -
@marty56 naja eine Datenbank schreibt Daten die gespeichert werden sollen. Wenn primär Daten dazu kommen sollte es an sich fast egal sein ob alles einmal pro Stunde oder direkt geschrieben wird. Bei SQLite wär ich mir da nicht gaaaanz so sicher ob das equivalent ist aber so weit auseinander sollte es auch wider nicht sein.
Datenbanken haben von Natur aus die Anforderung keine Daten zu verlieren ;-) also ob Du eine dB findest die das „bricht“ weiß ich nicht ;-)
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
-
@marty56 naja eine Datenbank schreibt Daten die gespeichert werden sollen. Wenn primär Daten dazu kommen sollte es an sich fast egal sein ob alles einmal pro Stunde oder direkt geschrieben wird. Bei SQLite wär ich mir da nicht gaaaanz so sicher ob das equivalent ist aber so weit auseinander sollte es auch wider nicht sein.
Datenbanken haben von Natur aus die Anforderung keine Daten zu verlieren ;-) also ob Du eine dB findest die das „bricht“ weiß ich nicht ;-)
@apollon77 Hat sich denn im controller etwas geändert? Ich habe ja schon seit Monaten 'jsonl' in Betrieb und die geschriebene Datenmenge war seitdem erfreulich gering. Doch seit Ende Juli als die ganzen Updates aufschlugen habe ich wieder eine extreme Schreiblast laut Proxmox (etwa hundertfach!). Laut htop ist es der Prozess iobroker.js-controller. Mit deutlichem Abstand folgt io.backitup.0. Ich habe mal alle Instanzen gruppenweise deaktiviert. Da hat sich nichts geändert. Erst wenn iobroker gestoppt wird, fallen die Schreibzugriffe wieder auf faktisch Null.
-
@apollon77 Hat sich denn im controller etwas geändert? Ich habe ja schon seit Monaten 'jsonl' in Betrieb und die geschriebene Datenmenge war seitdem erfreulich gering. Doch seit Ende Juli als die ganzen Updates aufschlugen habe ich wieder eine extreme Schreiblast laut Proxmox (etwa hundertfach!). Laut htop ist es der Prozess iobroker.js-controller. Mit deutlichem Abstand folgt io.backitup.0. Ich habe mal alle Instanzen gruppenweise deaktiviert. Da hat sich nichts geändert. Erst wenn iobroker gestoppt wird, fallen die Schreibzugriffe wieder auf faktisch Null.
@dr-bakterius Geändert hat sich nichts. Der controller 3.3 hat ne neue Version der jsonl mitgebracht und wenn Du immer noch jsonl nutzt dann sollte das auch weiterhin so sein. AUch bei jsonl hat sich nicht wirklich was geändert.
Also checke mal "iobroker setup custom" zuerst. ansonsten muss irgendein adapter "schuld" sein. Den müsstest Du dann finden denke ich
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 Geändert hat sich nichts. Der controller 3.3 hat ne neue Version der jsonl mitgebracht und wenn Du immer noch jsonl nutzt dann sollte das auch weiterhin so sein. AUch bei jsonl hat sich nicht wirklich was geändert.
Also checke mal "iobroker setup custom" zuerst. ansonsten muss irgendein adapter "schuld" sein. Den müsstest Du dann finden denke ich
@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Also checke mal "iobroker setup custom"
Current configuration: - Objects database: - Type: jsonl - Host/Unix Socket: 127.0.0.1 - Port: 9001 - States database: - Type: jsonl - Host/Unix Socket: 127.0.0.1 - Port: 9000 - Data Directory: ../../iobroker-data/Sieht soweit okay aus. Und wie gesagt, ich habe alle Instanzen gestoppt und trotzdem kommt es etwa alle drei Minuten zu einem hohen Diskwrite.
'htop' zeigt:
Und unter Proxmox sieht man den gewaltigen Anstieg:
Weiß echt nicht was ich noch prüfen könnte...
-
@apollon77 Hat sich denn im controller etwas geändert? Ich habe ja schon seit Monaten 'jsonl' in Betrieb und die geschriebene Datenmenge war seitdem erfreulich gering. Doch seit Ende Juli als die ganzen Updates aufschlugen habe ich wieder eine extreme Schreiblast laut Proxmox (etwa hundertfach!). Laut htop ist es der Prozess iobroker.js-controller. Mit deutlichem Abstand folgt io.backitup.0. Ich habe mal alle Instanzen gruppenweise deaktiviert. Da hat sich nichts geändert. Erst wenn iobroker gestoppt wird, fallen die Schreibzugriffe wieder auf faktisch Null.
@dr-bakterius seitdem jsonl angeboten wird, habe ich ioBroker umgestellt, habe die Diskwrites aber nicht weiter beobachtet.. Controller update habe ich auch schon eine Zeit lang gemacht.
So schaut es derzeit aus:
iobroker setup custom:Current configuration: - Objects database: - Type: jsonl - Host/Unix Socket: 0.0.0.0 - Port: 9001 - States database: - Type: jsonl - Host/Unix Socket: 0.0.0.0 - Port: 9000 - Data Directory: ../../iobroker-data/Was ich am 17.8. um 20 Uhr gemacht habe, das die Werte seit dem wieder höher sind muss ich mal recherchieren...
Edit: hmm nichts spannendes passiert, außer das wie vorher auch so ein paar Adapter abfragen starten..
-
@dr-bakterius seitdem jsonl angeboten wird, habe ich ioBroker umgestellt, habe die Diskwrites aber nicht weiter beobachtet.. Controller update habe ich auch schon eine Zeit lang gemacht.
So schaut es derzeit aus:
iobroker setup custom:Current configuration: - Objects database: - Type: jsonl - Host/Unix Socket: 0.0.0.0 - Port: 9001 - States database: - Type: jsonl - Host/Unix Socket: 0.0.0.0 - Port: 9000 - Data Directory: ../../iobroker-data/Was ich am 17.8. um 20 Uhr gemacht habe, das die Werte seit dem wieder höher sind muss ich mal recherchieren...
Edit: hmm nichts spannendes passiert, außer das wie vorher auch so ein paar Adapter abfragen starten..
@fredf sagte in ioBroker sehr hohe Diskwrites in Proxmox:
iobroker setup custom
hab auch mal gerade geschaut, hab auch jsonl bei beidem drin seit langem. Disk io sieht bei mir unauffällig aus:
PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...
UDM Pro, Intel NUC - ioBroker in Proxmox-VM, PiHole+Grafana&Influx+TasmoAdmin in LXCs, Raspberry Pi3 (als CCU), Zigbee-Stick Sonoff, Synology DS918+
-
@fredf sagte in ioBroker sehr hohe Diskwrites in Proxmox:
iobroker setup custom
hab auch mal gerade geschaut, hab auch jsonl bei beidem drin seit langem. Disk io sieht bei mir unauffällig aus:
PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...
@kueppert sagte in ioBroker sehr hohe Diskwrites in Proxmox:
PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...
Einfach alles mit Enter bestätigen
Edit: Bzw. mit Strg + c abbrechen
-
@kueppert sagte in ioBroker sehr hohe Diskwrites in Proxmox:
PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...
Einfach alles mit Enter bestätigen
Edit: Bzw. mit Strg + c abbrechen
-
@fredf sagte in ioBroker sehr hohe Diskwrites in Proxmox:
iobroker setup custom
hab auch mal gerade geschaut, hab auch jsonl bei beidem drin seit langem. Disk io sieht bei mir unauffällig aus:
PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...
@kueppert sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Disk io sieht bei mir unauffällig aus
Also ich war vor dem Anstieg noch wesentlich weiter unten als du - jetzt habe ich mehr als das doppelte von dir.
Und wie gesagt, alle drei Minuten der Zugriff:
Wird jetzt sicher nicht gleich meine SSD schrotten, aber interessieren würde mich doch was das ist...
-
Dann wiederhole ich was ich oben geschrieben habe: da müsste ein Adapter „schuld“ sein. Finde raus welcher.
Alternativ schau was die jsonl files in iobroker-data machen. Sie müssten ja dann zu dem genannten Zeitpunkt neu komprimiert werden - ergo kleiner werden. Dann schau welches file es ist.
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
-
Dann wiederhole ich was ich oben geschrieben habe: da müsste ein Adapter „schuld“ sein. Finde raus welcher.
Alternativ schau was die jsonl files in iobroker-data machen. Sie müssten ja dann zu dem genannten Zeitpunkt neu komprimiert werden - ergo kleiner werden. Dann schau welches file es ist.
@apollon77 Ich habe jetzt über eine Stunde gesucht. Alle Instanzen beendet und dann der Reihe nach gestartet. Irgendwann sind die Schreibzugriffe angestiegen und häufiger geworden. Einen speziellen Adapter konnte ich dabei nicht ausmachen.
Die 'states.jsonl' steigt laufend in der Größe an, und wird wenn sie ungefähr die doppelte Größe erreicht hat neu geschrieben. Ich steh an... :confused:
701
Online32.7k
Users82.5k
Topics1.3m
Posts