EXPERIMENTELL: JsonL Datenbank für js-controller

[Dr. Bakterius]

@apollon77 Ich habe mal auf 20 Sekunden gestellt - dauert aber geht. Dann 5 Sekunden - geht auch. Und danach wieder auf 2 Sekunden. Geht jetzt plötzlich auch wieder. Dauert aber länger als gewöhnlich (wenn der Broker läuft geht es sofort). Der Host läuft auf Sparflamme und hat nicht viel zu tun. Was soll ich sagen...

Bleibt noch das Thema mit der nicht komprimierten objects.jsonl.

[apollon77]

@dr-bakterius Naja ok das es wenn iobroker nicht läuft kurz dauert (und bissl länger also bei controller 3.1.x) ist normal.

Wenn kein iobroker läuft dann ist die DB nicht da, also startet der CLI Kommando erstmal eine DB damit er dahin verbinden kann. Das sind halt die paar Sekunden. Und das muss er nicht wenns schon läuft - dann ists ja schon am laufen.

[Dr. Bakterius]

@apollon77 Okay, alles klar. Vielleicht dauert es jetzt länger weil die Datenbank größer ist? Mit zwei Sekunden hat es doch nicht geklappt (hatte zu speichern vergessen), aber mit drei Sekunden geht es jetzt.

[apollon77]

@dr-bakterius Wenn das einlesen einer jsonl DB wegen dem gewählten Ansatz länger dauert als das lesen und parten eines reinen JSOns (was gut sein kann), dann könnte da was dran sein.
@AlCalzone

[AlCalzone]

@dr-bakterius sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

Hieß es nicht doppelte Größe und 1.000 Zeilen? Es hat die dreifache Größe und über 10.000 Zeilen mehr!

Mit doppelte Größe war die Anzahl der Zeilen gemeint. @apollon77 hat das schon richtig wieder gegeben.

Komprimiert wird, wenn die Anzahl der Zeilen (d.h. Schreib- und Löschoperationen) in der Datei doppelt so hoch ist wie nötig und nur dann wenn diese Anzahl mindestens 1000 beträgt.
Es wäre also tatsächlich nach weiteren 287 Updates passiert. An den Zahlen können wir durchaus noch schrauben - das war ein erster Wurf.

Und ja, es kann sein, dass das Starten länger dauert, weil mehr geparsed wird. Ich hab ne Idee wie man das optimieren könnte. Kannst du deine (recht große) Objects DB teilen (auch gerne privat per E-Mail) oder stehen da zu viele Geheimnisse drin?

[Dr. Bakterius]

@alcalzone Okay, danke für die Erklärung. Dann habe ich dich beim ersten Mal falsch verstanden. Alles gut. Nachdem das ganze noch experimentell ist, vermutet man hinter jeder Sache gleich einen Bug.

Ich denke, mit 10.700 Objekten bin ich eher im Durchschnitt.

[Adnim]

Hi!
habe heute morgen umgestellt. Master läuft auf den ersten Blick einwandfrei. Disk I/o scheint nun in einer andern Welt zu sein.

Mein Slave bekomme ich aber noch nicht ins Rennen.

Bekomme nur die Fehlermeldung dort:
No Connection to Database Possible...

Current configuration:
- Objects database:
  - Type: jsonl
  - Host/Unix Socket: 192.165.175.15
  - Port: 9001
- States database:
  - Type: jsonl
  - Host/Unix Socket: 192.165.175.15
  - Port: 9000
- Data Directory: ../../iobroker-data/

Muss ich hier noch was anpassen?
Iobroker Log des Slaves hat auch nur die Fehlermeldung drinne, verbunden mit Restarts deswegen.

[apollon77]

@adnim wie sieht die Master konfig aus?

[Adnim]

@apollon77

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/

[apollon77]

@adnim Jupp der Master erlaubt nur lokale Verbindungen. Schreib in die konfig beim Master mal 0.0.0.0 als ip rein bei beiden dbs. Dann klappt’s auch.

[Adnim]

@apollon77

Ja dann klappts auch Danke!

Datenbank läuft Stabil, Write Load ist komplett verschwunden super Sache.

[FredF]

@apollon77 @AlCalzone
Angeregt durchs mitlesen des Disk Write Beitrags und auch schon längeren Überlegungen ob ich mein System auf redis umstellen soll oder nicht, habe ich mich nun mal getraut auf jsonl umzustellen.

Bilder sagen oft mehr als tausend Worte:

Controller Update aus 3.2.16 halbiert diskwrite

Umstellung auf jsonl, Disk write dast nicht mehr vorhanden

Einfach Toll wie mit euren stetigen Optimierungen und Verbesserungen die ihr anscheinend aus dem Nichts zaubert (kommt mir nicht wissenden zumindest so vor) ioBroker so weiter entwickelt wird.

Weiter so!

[Neuschwansteini]

@apollon77

sieht ja echt interessant aus, lohnt es sich von Redis auf jsonl umzustellen??

Ich betreibe auf dem iobroker auch ein Redisserver und n Slave auf der Syno..

[apollon77]

@ilovegym das musst du wissen. Am Ende kann redis genau so sparsam sein wenn man ihn richtig einrichtet ;-))

[Neuschwansteini]

@apollon77

Danke, ok, ich wart mal ab, was die Erfahrungen in den nächsten Wochen so zeigen, und wenn ich Zeit habe, teste ich das mit nem Clone mal aus.

Denke aber, mein Redis ist schon echt flott.

Bin gerade fertig mit der Umstellung von den Xiaomi-Gateways auf n CC26X2R, und hab 140 Sensoren neu angelernt..

[saeft_2003]

@ilovegym sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

Bin gerade fertig mit der Umstellung von den Xiaomi-Gateways auf n CC26X2R, und hab 140 Sensoren neu angelernt..

Wow 140... das Gleiche hatte ich vor ca. einem Jahr gemacht und da waren es „nur“ 50 Sensoren und das war schon eine große Arbeit

[Scrounger]

@apollon77 @AlCalzone
Anbei meine Erfahrungen mit jsonl, einfach nur top, super Arbeit

Disk IO pro Stunden liegt jetzt bei 260MiB, statt ursprünglich 35 GiB

Weiter ist mir aufgefallen, dass die CPU Last mit jsonl ebenfalls runter gegangen ist:

[crunchip]

@scrounger sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

Weiter ist mir aufgefallen, dass die CPU Last mit jsonl ebenfalls runter gegangen ist:

bei mir genau das Gegenteil

[Dr. Bakterius]

@crunchip sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

bei mir genau das Gegenteil

Bei mir ist die CPU-Last auch gestiegen. Jedoch nicht ganz so extrem sondern "nur" um ~65% (6,2% > 10,2%). Damit liegt sie etwas höher als zu Beginn mit file|file (9,7%).

[Adnim]

Meine CPU last hat sich auch um ca.2% erhöht, dafür keinerlei Schreibload mehr. Läuft Spitze. Maybee sollte das der neue StandartStandard werden mit JsonL!?