EXPERIMENTELL: JsonL Datenbank für js-controller
-
@apollon77 sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
So lange der js-controller CPU Technisch nicht mehr als 60-70% braucht
absolut im Rahmen mit JSONL
-
@crunchip Hier sollte sich JSONL und File-DB nicht anders verhalten ... FileDB hat vllt sogar etwas weniger CPU-Last
-
@apollon77 Hatte ja zu Beginn des Threads ja schon Umgestellt und berichtet, wegen dem Gesamt CPU Anstieg der VM, was dadurch weiter auf Ursachenforschung ging und feststellte, das der ein oder andere Adapter mit in die Suppe gespuckt hatte, z.b. wled
Ansonsten war das mein letzter Stand, siehe https://forum.iobroker.net/post/591902 -
Ich hab bei den Arbeiten für Controller 4 noch einiges an Optimierung gemacht (sofern @apollon77's Problem jetzt gelöst ist?).
Das hat bei mir den Durchsatz der DB-Lib um Faktor 15-30 erhöht, was sich in ioBroker aber vor allem in geringerer CPU-Last bzw. Latenz auswirken dürfte. -
Hi, moechte von Redis auf jsonL umstellen, hat sich da mit js-controller 4.x was noch geaendert, das man beachten sollte?
Der 4.x laeuft auf meinem System mit Redis einwandfrei, nur hat Redis bei mir in letzter Zeit ne recht hohe last und oefters kommt "slow connection to objects"... -
@ilovegym Mit js-controller 4 (Achtung aktuell Alpha!!) wird jsonl die neue Standard DB.
Aber jetzt mal einen Schritt zurück: Wenn Redis viel last hat und teilweise "slow connection" ckommt dasnn wird das mit sjonl eher schlechter als besser!! Was ist denn da los in deinem System? Schau mal an ob du instanzen hast die viele Daten senden und so.
Fakt ist immer noch das Redis ca. 25-30% mehr Durchsatz leistet als File oder jsonl ... also wenn du it Redis an grenzen stösst ... ... ...
-
@apollon77 ah ok, Danke, dann schau ich mal genauer, was viel frisst.. sind 75000 objects oder so.
Zur Zeit hab ich Multihost, der Master laeuft in einem lxc mit Debian 10(von 8 auf 9 auf 10 gezogen), dazu 4 Raspi's mit jeweils 1-3 Instanzen..Mein Plan ist, die Raspi's auf 1 zu minimieren, und Multihost mit mindestens 3 lxc auf mindestens 3 Nodes verteilt zu erstellen, um eben die Last zu verteilen und auch bei einem Ausfall einer Node/lxc nur ein Teilausfall zu haben.
Im Moment ist Zeit das groesste Problem, laufen tuts ja ..
-
@ilovegym Die reine Anzahl (die interessant hoch ist) ist nicht das Thema ... am Ende kommt die Last von Aktionen auf die DB ... und da schau mal welche Instanz da Daten "spammt" ... aber wenn Redis so "am Limit" ist dann ist eher die Farge ob die ne bessere CPU findest für den Redis LXC
Aber da bringt jsonl nicht viel denke ich.PS: Was sinds denn für Nucs? Ehere die "Nuc6 ecke" mit Pentiums/Celerons oder Nuc8 mit i5?
-
ah, deshalb.. redis laeuft im lxc von iobroker... und den hab ich zum Jahreswechsel vom HP DL380 G8 mit 2x Xeon E5-2680 128GB Ram 12TB SAS auf n NUC I 5 G8 mit 16GB gezogen.. er zeigt 30% CPU Last, braucht ca. 6GB Ram, hat keine nennenswerte I/O delays.. ( also alles mit Proxmox )
Hatte eigentlich vor, den HP Server zu verkaufen, da mit 200W / 45 Euro Strom im Monat schon n Unterschied zu den NUC's, da braucht einer 18W, hab davon mal 3 geholt..Wenn ich dadurch Performance Probleme bekomm, werf ich den HP wieder an.. Leistung sollte fuern Redis Container ausreichen
Sonoff-Adapter mit ca 140 Tasmota Devices, Zigbee Adapter mit 195 devices.. -
@ilovegym Ok, laaaaangsam!! Ich glaube Du hast es falsch verstanden.
Die Benchmark Tests die wir gemacht haben in den letzten Wochen zeigen interessante Dinge. Siehe auch https://www.iobroker.net/#de/blog/2021_12_15
Vor allem das die ganze "NUC5/6/7" Ecke mit Celeron/Pentium im Vergleich zu den i5 zB ab NUC8 aufwärts ein Mega Durchsatz Unterschied ist. Wie diesbezüglich Xeons abscheiden weiss ich nicht ... könntest mal Benchmark Adapter laufen lassen dann können wir es einordnen
Von daher ist der i5 schon gut
Anaonsten: Dein Redis braucht 6GB RAM????? Oder hab ich das gerade falsch verstanden? Dann solltest DU mal schauen ob nicht irgendein Adapter hier den ioBroker storage zumüllt (gabs letztens wo ein Adapter immer neue Bilder von ner Tür Kamera abgelegthat aber nie gelsöcht hat ... ergo x GB an "Bildern".
-
@apollon77 ok, das mit den Benchmarks schau ich mir mal in Ruhe an.
Nee Redis laeuft auf dem gleichen Host wie der ioBroker, das werde ich mal trennen, ist vielleicht ne gute Idee..
meinte der ganze Host braucht um die 6 GB Ram. Influx ist auf nem eigenen Host installiert.
So siehts zur Zeit aus, gerade mal connected, sieht doch ganz gechillt aus.. :
-
@ilovegym Wie viel ackern deine Skripte denn? Wenn das die permanente CPU-Last von Sonoff/Javascript/Redis ist, dann kommt mir das verdammt viel vor.
Ich mag zwar nicht ganz so viele aktive Adapter haben, aber das hier ist meine CPU-Last auf nem Pi3, der nicht so viel auf dem Kasten hat:
-
Jo interessant ... also mein System liegt bei redis so bei 2-3% und auch javascript liegt in dem Rahmen.
Aber ja wenn bei dir ggf der sonoff seeehr viele Daten reinbekommt (solltest du im Admin sehen können unter "Instanzen" im expertenmodus) dann hat es javascritp und redis auch weil JavaScript abonniert im Standard "alles".
-
@ilovegym sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
@apollon77 ok, das mit den Benchmarks schau ich mir mal in Ruhe an.
Schreib mich an dann geb ich dir alle infos
-
ich habe mal spaßeshalber die States type von Redis auf jsonl umgestellt.
Danach dauert es eine gefühlte Ewigkeit, bis nach einem Neustart Adapter wie VIS wieder oben sind. Zurück auf Redis kann ich nach wenigen Sekunden die VIS-Seiten schon wieder im Browser betrachten.
Die Objects type ist bei mir auf jsonl. Da wurde beim Update wohl automatisch von File her umgestellt. Ist es ratsam für höhere Geschwindigkeit die Objekte auf Redis umzustellen?
-
@peterfido sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
Danach dauert es eine gefühlte Ewigkeit, bis nach einem Neustart Adapter wie VIS wieder oben sind. Zurück auf Redis kann ich nach wenigen Sekunden die VIS-Seiten schon wieder im Browser betrachten.
Was genau meinst du? Meinst du "bis die Vis gestartet ist" oder meinst du "Bis die Adapter gestartet sind"?
Wie "groß" sind denn deine Visus so? Je nachdem wieviele Daten geladen werden müssen kann das schon einen Unterschied machen. Redis hat da halt einen größeren Durchsatz.
Die Objects type ist bei mir auf jsonl. Da wurde beim Update wohl automatisch von File her umgestellt. Ist es ratsam für höhere Geschwindigkeit die Objekte auf Redis umzustellen?
--> https://forum.iobroker.net/topic/26327/redis-in-iobroker-überblick
Bitte dort lesen und ggf diskutieren ... Da gibt es keine klare Ja oder Nein Antwort
-
ich meine die Zeit nach einem Neustart der ioBroker VM bis die Clienten die VIS wieder darstellen können. Bei Redis geht das unter einer Minute. Bei jsonl dauert es mehrere Minuten, bis die Clienten die VIS wieder erreichen.
-
@peterfido Da müsste man jetzt mal logfiles anschauen und exakt vergleichen ... Aber ja, wie gesagt - je nach Anzahl der Objekte und States kann das schon sein das hier ein Durchsatz Unterschied existiert. Redis hat generell gegenüber file/jsonl einen vorteil von 30-50% mehr Durchsatz
