NEWS
EXPERIMENTELL: JsonL Datenbank für js-controller
-
Die ersten 30 Minuten läuft alles wie bisher. In der iobroker.json habe ich den Eintrag '"writeFileInterval": 3600000,' entfernt. Und laut Proxmox-Grafik wird tatsächlich noch weniger auf die Platte geschrieben:
Mal sehen wie es aussieht, wenn die Dateien komprimiert und neu geschrieben werden. Die states.jsonl ist in dieser Zeit um ca. 90% gewachsen und die objects.jsonl um etwa 15%.
Wie sieht es eigentlich mit Backups aus? Unterstützt backitup die neue Datenbank schon?
@dr-bakterius backitup müsste den normalen Backup Befehl von ioBroker nutzen. Das ist dB unabhängig. Mir wäre neu das die json files geschrieben werden
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
-
weil's grad so langweilig ist, teste ich auch mal mit, mal sehen, wie sich das "Experiment" schlägt
das Timing nur etwas ungünstig gewählt, hoffe er wird noch vor 0:00 fertig mit seiner Migration:thinking_face: -
@dr-bakterius backitup müsste den normalen Backup Befehl von ioBroker nutzen. Das ist dB unabhängig. Mir wäre neu das die json files geschrieben werden
@apollon77 sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Das ist dB unabhängig.
Okay, wollte mich nur vergewissern.
Übrigens in 12 Stunden wurden 25 MiB geschrieben. Am Tag wären das also 50 MiB. Davor hatte ich am Tag 12 GiB mit redis und die objects nur einmal die Stunde als file mit dem neuen controller. Und das war schon deutlich (~90%) weniger als bei file/file und dem vorherigen controller. Also eine gewaltige Reduktion auf praktisch Null! Die gelesenen Daten sind bei mir etwa 100x so hoch - doch das wirkt sich auf das Speichermedium kaum aus.
-
Ich würd das gern mal grob Gegenrechnen. Sag mal wie groß die „alten“ objects.json bzw States.json sind ... also nicht die jsonl files.
Und .... waren die 190gb mit dem 1h objects speichern oder davor?
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
-
Hallo,
der neue js-controller 3.2 beinhaltet unter der Haube einige Änderungen und Aufräumarbeiten. EIne große davon ist, dass wir die Datenbank-Bibliotheken modularisiert haben und künftig flexibler zu sein und einfacher weitere Arten der Speicherung bereitstellen können.
Jetzt wo der js-controller mit 3.2.16 fast schon stable ist möchten wir eine erste solche neue Datenbank, die wir gerade experimentell ausprobieren mal vorstellen und vor allem den Usern mit dem Ziel die "Schreiblast bestmöglich zu verringern" (siehe https://forum.iobroker.net/topic/41128/iobroker-sehr-hohe-diskwrites-in-proxmox) anbieten das mal zu testen.
Wenn alles klappt wird das im js-controller 3.3 vllt die neue Standard Datenbank ... mal sehen :-)Diese neue Datenbank benutzt eine Bibliothek von @AlCalzone, welche das File nicht in definierten Abständen einfach neu schreibt, sondern erst einmal neue Daten anhängt (mindestens jede Minute oder nach Erreichen einer bestimmten Anzahl an Änderungen). Dann nach einer gewissen Anzahl an gesamten Änderungen wird das File komprimiert und neu geschrieben.
Mit diesem AOF-(Append Only File) Ansatz sollte sich die Schreiblast noch mehr verringern als wir es mit der letzten controller Optimierung geschafft haben.Das ganze ist alles noch EXPERIMENTELL, also auf eigene Gefahr, läuft bei uns aber schon in Testsystemen stabil. Feature Technisch gibt es noch ein paar Dinge zu tun (wie zB gepackte Backups und s ... das kommt noch)
Wie bekommt man es:
- WENN js-controller 3.2.16 ist (bei js-controller 3.3 NICHT nötig!!)
- Sicherstellen das mindestens js-controller 3.2.16 installiert ist
- cd /opt/iobroker/node_modules/iobroker.js-controller
- npm i @iobroker/db-states-jsonl @iobroker/db-objects-jsonl
- ACHTUNG: wer npm 7 hat bitte VOR der Installation mal hier melden weil es scheinbar mit dem hier genannten Vorgehen Probleme geben kann.
- ioBroker stoppen
- iobroker setup custom
- Bei multihost der master zuerst
- hier als db type "jsonl" eingeben bei beiden/dengewünschten DBs, Port Angaben und so einfach lassen wie vorher
- dann Wählen (beim mster bzw single host sowieso) das er migriert (Bei Slaves natürlich keine Migration)
- Danach sollte in /opt/iobroker/iobroker-data eine objects.jsonl und states.jsonl liegen (parallel zu den alten json files)
- iobroker starten ... i/o beobachten :-)
- die jsonl Files werden zuerst wachsen und dann nach einiger Zeit wieder kleiner werden
@AlCalzone und ich sind gespannt auf Eure I/O Erfahrungen :-)
Ingo und AlCalzone
@apollon77 sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
jsonl
Die Umstellung von redis/redis auf jsonl/redis ist bei mir ohne Probleme durchgelaufen. Der iobroker ist anschließend auch ohne Fehler gestartet.
Bei mir wurden vorher (nachdem ich die Speicherzyklen für die redis-Datenbank auf alle 12h reduziert hatte) rund 10GB/d geschrieben. Ich werde berichten, wie sich das System mit der neuen Datenbank verhält.
Gruß Marco
- WENN js-controller 3.2.16 ist (bei js-controller 3.3 NICHT nötig!!)
-
geb hier auch mal meinen Stand, nach rund 8Std kund.Ingesamt viel "ruhiger", hochgerechnet, komm ich auf rund 7,5GB diskwrite pro Tag.
Ob sich das in Zukunft bewährt, oder irgendwelche Probleme dadurch entstehen, wird sich noch zeigen.
zum Vergleich, die alten Werte, siehe
https://forum.iobroker.net/post/565703
https://forum.iobroker.net/post/564780
https://forum.iobroker.net/post/564691Was mir jedoch nun noch negativ aufgefallen ist, der Anstieg der CPU
vllt auch noch Nennenswert, welche/wie viele Instanzen aktiv laufen
umgestiegen von Proxmox auf Unraid
-
geb hier auch mal meinen Stand, nach rund 8Std kund.Ingesamt viel "ruhiger", hochgerechnet, komm ich auf rund 7,5GB diskwrite pro Tag.
Ob sich das in Zukunft bewährt, oder irgendwelche Probleme dadurch entstehen, wird sich noch zeigen.
zum Vergleich, die alten Werte, siehe
https://forum.iobroker.net/post/565703
https://forum.iobroker.net/post/564780
https://forum.iobroker.net/post/564691Was mir jedoch nun noch negativ aufgefallen ist, der Anstieg der CPU
vllt auch noch Nennenswert, welche/wie viele Instanzen aktiv laufen
@crunchip den CPU Verbrauch hast du nur absolut gell?! Also weiß nicht welcher Prozess das ggf 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
-
geb hier auch mal meinen Stand, nach rund 8Std kund.Ingesamt viel "ruhiger", hochgerechnet, komm ich auf rund 7,5GB diskwrite pro Tag.
Ob sich das in Zukunft bewährt, oder irgendwelche Probleme dadurch entstehen, wird sich noch zeigen.
zum Vergleich, die alten Werte, siehe
https://forum.iobroker.net/post/565703
https://forum.iobroker.net/post/564780
https://forum.iobroker.net/post/564691Was mir jedoch nun noch negativ aufgefallen ist, der Anstieg der CPU
vllt auch noch Nennenswert, welche/wie viele Instanzen aktiv laufen
@crunchip sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
der Anstieg der CPU
Das würde ich mir gerne mal genau anschauen. Kannst du einen Adapter, der viele Events hat, mal wie folgt manuell starten?
cd /opt/iobroker/node_modules/iobroker.<adaptername> node --prof main.jsEtwas laufen lassen, dann beenden. Du solltest eine Datei finden, die mit
v8.logendet.
Diese bitte umwandeln mitnode --prof-process --preprocess *v8.log > processed.txtund mir die Datei
processed.txtschicken.Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@crunchip den CPU Verbrauch hast du nur absolut gell?! Also weiß nicht welcher Prozess das ggf ist.
@apollon77 nein leider nicht, ist mir halt nur laut Proxmox Anzeige aufgefallen und bisher auch noch nicht weiter verfolgt
-
@crunchip sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
der Anstieg der CPU
Das würde ich mir gerne mal genau anschauen. Kannst du einen Adapter, der viele Events hat, mal wie folgt manuell starten?
cd /opt/iobroker/node_modules/iobroker.<adaptername> node --prof main.jsEtwas laufen lassen, dann beenden. Du solltest eine Datei finden, die mit
v8.logendet.
Diese bitte umwandeln mitnode --prof-process --preprocess *v8.log > processed.txtund mir die Datei
processed.txtschicken.@alcalzone Macht das Sinn beim Adapter?? Wenn es an der dB liiert kann’s doch nur der Master Controller sein
-
@crunchip sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
der Anstieg der CPU
Das würde ich mir gerne mal genau anschauen. Kannst du einen Adapter, der viele Events hat, mal wie folgt manuell starten?
cd /opt/iobroker/node_modules/iobroker.<adaptername> node --prof main.jsEtwas laufen lassen, dann beenden. Du solltest eine Datei finden, die mit
v8.logendet.
Diese bitte umwandeln mitnode --prof-process --preprocess *v8.log > processed.txtund mir die Datei
processed.txtschicken.@alcalzone sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
node --prof-process --preprocess *v8.log > processed.txt
hab ich erledigt, habe mal den sonoff Adapter dafür hergenommen, Text Datei hat 4mb, wohin soll ich sie schicken?
-
-
@apollon77 könntest Recht haben... Kann @crunchip den auch einfach mit dem Flag starten?
@crunchip müsstest du einfach hier hochladen können oder geht das nicht?
umgestiegen von Proxmox auf Unraid
-
@crunchip Da sieht man tatsächlich nichts von der DB. Bin mir gerade nicht sicher, wie man den Controller selbst mit dem Flag starten kann.
@alcalzone am Ende startest du die Main.js oder Controller.js. (Geht beides). Grad unterwegs. Daher ganzen Pfad tippen blöd.
-
Ich würd das gern mal grob Gegenrechnen. Sag mal wie groß die „alten“ objects.json bzw States.json sind ... also nicht die jsonl files.
Und .... waren die 190gb mit dem 1h objects speichern oder davor?
@apollon77 sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Ich würd das gern mal grob Gegenrechnen. Sag mal wie groß die „alten“ objects.json bzw States.json sind ... also nicht die jsonl files.
Die hatten etwa 15 MB (objects) bzw. 2,5 MB (states).
Und .... waren die 190gb mit dem 1h objects speichern oder davor?
Also begonnen hat die Aktion bei mir mit ca. 250 GB / Tag. Das konnte ich etwas reduzieren indem ich den Zyklus von netatmo und daswetter reduziert habe. Nach der Umstellung auf redis für die states und die objects nur einmal pro Stunde schreiben, hatte ich dann rund 23 GB pro Tag. Der neue Controller hat das auf 12 GB pro Tag reduziert. Und jetzt mit jsonl / jsonl komme ich auf 118 MB am Tag.
Wobei mir in den Proxmox-Grafiken noch nicht aufgefallen ist, dass die Dateien gepackt und neu geschrieben wurden. Wie oft passiert das? Denn die 118 MB kommen mir schon wenig vor.
Die CPU-Last ist bei mir auch wieder in die Höhe gegangen (~50% mehr). Durch redis konnte ich gegenüber file aber zuvor die Belastung senken. Jetzt ist sie vielleicht etwas höher als unter file / file. Laut htop verursacht der js-controller die mit Abstand höchste CPU-Last.
-
also würde dann so aussehen, oder?
cd /opt/iobroker/node_modules/iobroker.js-controller node --prof main.js *bzw* node --prof controller.jsund dann iobroker stoppen, starten?
-
@apollon77 sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Ich würd das gern mal grob Gegenrechnen. Sag mal wie groß die „alten“ objects.json bzw States.json sind ... also nicht die jsonl files.
Die hatten etwa 15 MB (objects) bzw. 2,5 MB (states).
Und .... waren die 190gb mit dem 1h objects speichern oder davor?
Also begonnen hat die Aktion bei mir mit ca. 250 GB / Tag. Das konnte ich etwas reduzieren indem ich den Zyklus von netatmo und daswetter reduziert habe. Nach der Umstellung auf redis für die states und die objects nur einmal pro Stunde schreiben, hatte ich dann rund 23 GB pro Tag. Der neue Controller hat das auf 12 GB pro Tag reduziert. Und jetzt mit jsonl / jsonl komme ich auf 118 MB am Tag.
Wobei mir in den Proxmox-Grafiken noch nicht aufgefallen ist, dass die Dateien gepackt und neu geschrieben wurden. Wie oft passiert das? Denn die 118 MB kommen mir schon wenig vor.
Die CPU-Last ist bei mir auch wieder in die Höhe gegangen (~50% mehr). Durch redis konnte ich gegenüber file aber zuvor die Belastung senken. Jetzt ist sie vielleicht etwas höher als unter file / file. Laut htop verursacht der js-controller die mit Abstand höchste CPU-Last.
@dr-bakterius sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Wobei mir in den Proxmox-Grafiken noch nicht aufgefallen ist, dass die Dateien gepackt und neu geschrieben wurden. Wie oft passiert das? Denn die 118 MB kommen mir schon wenig vor.
By default nach folgenden Regeln:
- Beim Start von ioBroker und
- Wenn die Datei auf die doppelte tatsächlich benötigte Größe angewachsen ist, aber erst wenn sie mindestens 1000 Zeilen enthält.
Je nachdem, wie oft es bei dir Veränderungen gibt, kann das sehr selten passieren. Da sich hauptsächlich die States verändern sollten, werden dann jedesmal so um die 2,5 MB geschrieben. Alle anderen Schreibzugriffe sind eher im Byte- bis max. Kilobyte-Bereich.
@crunchip Ich glaube vorher iobroker stoppen, dann den genannten Befehl. Und irgendwann ioBroker mit Strg+C beenden.
Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@dr-bakterius sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Wobei mir in den Proxmox-Grafiken noch nicht aufgefallen ist, dass die Dateien gepackt und neu geschrieben wurden. Wie oft passiert das? Denn die 118 MB kommen mir schon wenig vor.
By default nach folgenden Regeln:
- Beim Start von ioBroker und
- Wenn die Datei auf die doppelte tatsächlich benötigte Größe angewachsen ist, aber erst wenn sie mindestens 1000 Zeilen enthält.
Je nachdem, wie oft es bei dir Veränderungen gibt, kann das sehr selten passieren. Da sich hauptsächlich die States verändern sollten, werden dann jedesmal so um die 2,5 MB geschrieben. Alle anderen Schreibzugriffe sind eher im Byte- bis max. Kilobyte-Bereich.
@crunchip Ich glaube vorher iobroker stoppen, dann den genannten Befehl. Und irgendwann ioBroker mit Strg+C beenden.
@alcalzone sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Wenn die Datei auf die doppelte tatsächlich benötigte Größe angewachsen ist, aber erst wenn sie mindestens 1000 Zeilen enthält.
Okay. Meine ursprüngliche objects.json ist 15.447.160 Byte groß. Aktuell hat die objects.jsonl 34.758.338 Byte und 18.553 Zeilen.
Ich denke, damit sollten beide Voraussetzungen für das Packen und Neuschreiben erfüllt sein, oder?
PS: Gerade gesehen, dass zumindest die states.jsonl neu erstellt wurde.
-
@alcalzone sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Wenn die Datei auf die doppelte tatsächlich benötigte Größe angewachsen ist, aber erst wenn sie mindestens 1000 Zeilen enthält.
Okay. Meine ursprüngliche objects.json ist 15.447.160 Byte groß. Aktuell hat die objects.jsonl 34.758.338 Byte und 18.553 Zeilen.
Ich denke, damit sollten beide Voraussetzungen für das Packen und Neuschreiben erfüllt sein, oder?
PS: Gerade gesehen, dass zumindest die states.jsonl neu erstellt wurde.
@dr-bakterius sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Ich denke, damit sollten beide Voraussetzungen für das Packen und Neuschreiben erfüllt sein, oder?
Es kommt nicht auf die Größe an, sondern was man damit macht 😂
Nein, Spaß beiseite. Wie viele Zeilen hatte die originale objects.jsonl?
Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
Support us
618
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge