NEWS
EXPERIMENTELL: JsonL Datenbank für js-controller
-
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/ -
@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.
Ja dann klappts auch
Danke!Datenbank läuft Stabil, Write Load ist komplett verschwunden super Sache.
-
@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:
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!
-
@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.
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..
-
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..
-
@ilovegym das musst du wissen. Am Ende kann redis genau so sparsam sein wenn man ihn richtig einrichtet ;-))
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..
-
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..
@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
-
@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:
<a href="https://github.com/Scrounger/ioBroker.linkeddevices">LinkedDevices Adapter</a>
<a href="https://github.com/Scrounger/ioBroker.vis-materialdesign">Material Design Widgets</a>
-
@apollon77 @AlCalzone
Anbei meine Erfahrungen mit jsonl, einfach nur top, super ArbeitDisk 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:
@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
umgestiegen von Proxmox auf Unraid
-
@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
@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%).
-
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!?
@adnim
a) Standard ist keine Standart.b) In deinem Fall sehe ich einen Anstieg wie bei mir um ~65% (von 2% auf 3,5%) oder 1,5%-Punkte.
-
@adnim
a) Standard ist keine Standart.b) In deinem Fall sehe ich einen Anstieg wie bei mir um ~65% (von 2% auf 3,5%) oder 1,5%-Punkte.
@dr-bakterius
danke für den Hinweis! Ja Prozentual ist der Anstieg schon heftig. Aber da bin ich ganz entspannt das kostet mich etwas Strom, CPU hat ja keinen Verschleiß wie eine Festplatte. Wenn man das noch in den Griff bekommt umso besser, lüppt aber auch so...
-
@dr-bakterius
danke für den Hinweis! Ja Prozentual ist der Anstieg schon heftig. Aber da bin ich ganz entspannt das kostet mich etwas Strom, CPU hat ja keinen Verschleiß wie eine Festplatte. Wenn man das noch in den Griff bekommt umso besser, lüppt aber auch so...
@adnim Stimme dir eh zu - finde das neue Konzept bisher auch toll. Wobei eine CPU und die anderen Komponenten natürlich auch schneller altern je höher sie belastet werden. Doch das ist bei diesen Werten und im Vergleich zu den Datenträgern wirklich zu vernachlässigen.
-
@apollon77 @AlCalzone
Anbei meine Erfahrungen mit jsonl, einfach nur top, super ArbeitDisk 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:
Bei mir sieht es bzgl. der Diskwrites sehr ähnlich aus:
Nach der Einstellung geringerer Schreibzyklen für redis (States und Objects) ist die Schreiblast deutlich runtergegangen. Mit der Umstellung auf die aktuelle Version des js-controller und jsonl (erst nur Objects dann States und Objects) ist ein weiterer spürbarer Rückgang zu verzeichnen.
Die CPU-Auslastung geht - insbesondere seit auch die States in der jsonl-DB liegen - spürbar nach oben (~+40 % von 3,25% auf 4,5%).
Gruß Marco
iobroker im Container (debian Bullseye) unter proxmox 7.1
debmatic in VM (debian Buster) unter proxmox 7.1 mit HB-RF-USB und RPI-RF-MOD
40 HomeMatic Geräte, Phillips Hue, Ikea Tradfri, Logitech Harmony Hub, Botvac Connected, Robonect -
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!?
@adnim sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Maybee sollte das der neue Standard werden mit JsonL!?
Wieviele hatten denn seit ihrer Umstellung Situationen, in denen das neue Schreibverfahren seine Robustheit unter Beweis stellen konnte?
-
Bei mir sieht es bzgl. der Diskwrites sehr ähnlich aus:
Nach der Einstellung geringerer Schreibzyklen für redis (States und Objects) ist die Schreiblast deutlich runtergegangen. Mit der Umstellung auf die aktuelle Version des js-controller und jsonl (erst nur Objects dann States und Objects) ist ein weiterer spürbarer Rückgang zu verzeichnen.
Die CPU-Auslastung geht - insbesondere seit auch die States in der jsonl-DB liegen - spürbar nach oben (~+40 % von 3,25% auf 4,5%).
Gruß Marco
@lonsimbt sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
3,25% auf 4,5%
Das ist jetzt alles nicht so die Welt, aber wir haben bereits grundlegend was in der File DB identifiziert (der Teil, der auch von JSONL genutzt wird), was das verursachen könnte.
-
Bei mir sieht es bzgl. der Diskwrites sehr ähnlich aus:
Nach der Einstellung geringerer Schreibzyklen für redis (States und Objects) ist die Schreiblast deutlich runtergegangen. Mit der Umstellung auf die aktuelle Version des js-controller und jsonl (erst nur Objects dann States und Objects) ist ein weiterer spürbarer Rückgang zu verzeichnen.
Die CPU-Auslastung geht - insbesondere seit auch die States in der jsonl-DB liegen - spürbar nach oben (~+40 % von 3,25% auf 4,5%).
Gruß Marco
@lonsimbt sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Die CPU-Auslastung geht - insbesondere seit auch die States in der jsonl-DB liegen - spürbar nach oben (~+40 % von 3,25% auf 4,5%).
Naja das ist aber zu erwarten!!
Bisher hatte die Redis DB und damit der Redis Prozess die Last wenn dort die Daten auch lagen. Wenn das jetzt wieder in die File DB kommt die vom controller Prozess dann gemanaged wird dann geht die CPU Last hierauf über und ist normalerweise mehr als Redis weil redis "nativ C++" ist nd kein interpretiertes Javascript.
Da müsste Ihr aufpassen nicht Äpfel mit Birnen zu vergleichen
-
@lonsimbt sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Die CPU-Auslastung geht - insbesondere seit auch die States in der jsonl-DB liegen - spürbar nach oben (~+40 % von 3,25% auf 4,5%).
Naja das ist aber zu erwarten!!
Bisher hatte die Redis DB und damit der Redis Prozess die Last wenn dort die Daten auch lagen. Wenn das jetzt wieder in die File DB kommt die vom controller Prozess dann gemanaged wird dann geht die CPU Last hierauf über und ist normalerweise mehr als Redis weil redis "nativ C++" ist nd kein interpretiertes Javascript.
Da müsste Ihr aufpassen nicht Äpfel mit Birnen zu vergleichen
@apollon77 sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
@lonsimbt sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Die CPU-Auslastung geht - insbesondere seit auch die States in der jsonl-DB liegen - spürbar nach oben (~+40 % von 3,25% auf 4,5%).
Naja das ist aber zu erwarten!!
Bisher hatte die Redis DB und damit der Redis Prozess die Last wenn dort die Daten auch lagen. Wenn das jetzt wieder in die File DB kommt die vom controller Prozess dann gemanaged wird dann geht die CPU Last hierauf über und ist normalerweise mehr als Redis weil redis "nativ C++" ist nd kein interpretiertes Javascript.
Da müsste Ihr aufpassen nicht Äpfel mit Birnen zu vergleichen
Bei mir laufen (bzw. liefen) redis und iobroker im gleichen Container, d. h. der Unterschied dürfte tatsächlich aus dem höheren Aufwand stammen, den der Javascript-Code erzeugt. Ich persönlich finde den Anstieg um gut einen Prozentpunkt auch überhaupt nicht tragisch. Mein kleiner Server langweilt sich sowieso den Großteil der Zeit... Ich wollte nur meine Beobachtungen kundtun, da mit dem neuen Datenbankformat offensichtlich unterschiedliches Verhalten beobachtet wurde.
Gruß Marco
Support us
432
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge