UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[crunchip]

@apollon77 ok, mach ich und teste mal

[crunchip]

@apollon77 soll ich danach `connenctTimeout wieder zurückstellen?
update ist durch, was mich aber gewundert hat, iobroker lief selbstständig wieder an, ohne iobroker start?
wollte eigentlich noch nen iobroker fix hinterher schieben

[apollon77]

@crunchip Ja beim ersten update von <3.3 auf 3.3 passiert das. danach nicht mehr. das timeout kann wieder runtergesetzt werden

[FredF]

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

Wenn alles klappt wird das im js-controller 3.3 vllt die neue Standard Datenbank ... mal sehen

Ich nutze jsonl nun von Anfang an und kann nichts negatives berichten, es läuft einfach
Wie es denn hier der Stand? Standard oder nicht? Es gibt ja einige die redis noch nutzen...

[apollon77]

@fredf laaamngsam … keine Äpfel mit Birnen vergleichen bitte. Der Controller 4 wechselt vielleicht (!!!!) bei filedb automatisch auf jsonl. Das sehen wir noch …

Und auch dann hat redis seine Zielgruppe. Man muss nur halt das Tool einsetzen was für einen und sein System sinnvoll ist.

[Thomas Braun]

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

Man muss nur halt das Tool einsetzen was für einen und sein System sinnvoll ist.

Gibt es dahingehend Vorschläge oder Einschätzungen, wann welches Tool angebracht sein könnte?

[Ein ehemaliger Benutzer]

@apollon77

hab das gerade mal versucht von redis auf jsonl umzustellen, er bricht mir ab mit dem Fehler, dass iobroker noch laufen wuerde..
dabei habe ich vorher ein iobroker fix gemacht und er ist durch gelaufen.

Dann nochmal versucht, wieder das gleiche. Js-controller ist 3.3.22, Rest auf Beta.

ilovegym@VMC123-iobroker /opt/iobroker $ iobroker stop
ilovegym@VMC123-iobroker /opt/iobroker $ iobroker status
iobroker is not running on this host.

At least one iobroker host is running.

Objects type: redis
States  type: redis
ilovegym@VMC123-iobroker /opt/iobroker $ iobroker setup custom
Current configuration:
- Objects database:
  - Type: redis
  - Host/Unix Socket: 127.0.0.1
  - Port: 6379
- States database:
  - Type: redis
  - Host/Unix Socket: 127.0.0.1
  - Port: 6379

Type of objects DB [(f)ile, (r)edis, ...], default [redis]: jsonl
Host / Unix Socket of objects DB(jsonl), default[127.0.0.1]:
Port of objects DB(jsonl), default[9001]:
Type of states DB [(f)file, (r)edis, ...], default [jsonl]:
Host / Unix Socket of states DB (jsonl), default[127.0.0.1]:
Port of states DB (jsonl), default[9000]:
Data directory (file), default[../../iobroker-data/]:
Host name of this machine [VMC123-iobroker]:
It appears that you want to convert this slave host into a Master or Single host system. Is this correct? [Y/n]: y

Do you want to migrate objects and states from "redis/redis" to "jsonl/jsonl" [y/N]: y

Migrating the objects database will overwrite all objects! Are you sure that this is not a slave host and you want to migrate the data? [y/N]: y

Connecting to previous DB "redis"...

Cannot migrate DB while js-controller is still running!
Please stop ioBroker and try again. No settings have been changed.
ilovegym@VMC123-iobroker /opt/iobroker $ ps -aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.1  22000  9800 ?        Ss   15:49   0:00 /sbin/init
root          56  0.0  0.2  29588 12376 ?        Ss   15:50   0:00 /lib/systemd/systemd-journald
_rpc          94  0.0  0.0   6828  3536 ?        Ss   15:50   0:00 /sbin/rpcbind -f -w
root          97  0.0  0.0 225828  3488 ?        Ssl  15:50   0:00 /usr/sbin/rsyslogd -n -iNONE
message+      99  0.0  0.0   8976  4280 ?        Ss   15:50   0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-onl
root         103  0.0  0.0   4684  3768 ?        Ss   15:50   0:00 /bin/bash /opt/iobroker/wetterstation.sh
root         104  0.0  0.1  19528  7116 ?        Ss   15:50   0:00 /lib/systemd/systemd-logind
root         179  0.0  0.0  76472  3064 ?        Ssl  15:50   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 110:116
root         180  0.0  0.1  15856  6860 ?        Ss   15:50   0:00 /usr/sbin/sshd -D
redis        184  0.0 15.6 1197652 939944 ?      Ssl  15:50   1:03 /usr/bin/redis-server 0.0.0.0:6379
root         345  0.0  0.0  43480  3920 ?        Ss   15:50   0:00 /usr/lib/postfix/sbin/master -w
postfix      347  0.0  0.1  43820  7060 ?        S    15:50   0:00 pickup -l -t unix -u -c
postfix      348  0.0  0.1  43872  7188 ?        S    15:50   0:00 qmgr -l -t unix -u
root         355  0.0  0.0   5516  2160 ?        Ss   15:50   0:00 /usr/sbin/cron -f
root         356  0.0  0.0   2424  1544 pts/0    Ss+  15:50   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 linux
root         357  0.0  0.0   2424  1664 pts/2    Ss+  15:50   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud tty2 115200,38400,9600 linux
root         358  0.0  0.0   2424  1656 pts/1    Ss+  15:50   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud tty1 115200,38400,9600 linux
root         360  0.0  0.0   6428  2240 ?        S    15:50   0:00 /usr/sbin/CRON -f
root         373  0.0  0.0   2392   748 ?        Ss   15:50   0:00 /bin/sh -c sleep 600 && systemctl start wetterstation
root         375  0.0  0.0   2300   736 ?        S    15:50   0:00 sleep 600
root         382  0.0  0.0 829944  5516 ?        Ssl  15:50   0:00 adb -L tcp:5037 fork-server server --reply-fd 4
root         474  0.0  0.1  16636  7720 ?        Ss   15:50   0:00 sshd: ilovegym [priv]
root         487  0.0  0.1  16636  7620 ?        Ss   15:50   0:00 sshd: ilovegym [priv]
ilovegym     489  0.0  0.1  21164  8968 ?        Ss   15:50   0:00 /lib/systemd/systemd --user
ilovegym     490  0.0  0.0  23116  2332 ?        S    15:50   0:00 (sd-pam)
ilovegym     513  0.0  0.0  16920  5008 ?        S    15:50   0:00 sshd: ilovegym@notty
ilovegym     514  0.0  0.1  17104  6072 ?        R    15:50   0:00 sshd: ilovegym@pts/3
ilovegym     515  0.0  0.0   2460  1724 ?        Ss   15:50   0:00 /usr/lib/openssh/sftp-server
ilovegym     516  0.0  0.0   5508  4708 pts/3    Ss   15:50   0:00 -bash
ilovegym     517  0.0  0.0   3656  2652 ?        Ss   15:50   0:00 bash -c while true; do sleep 1;head -v -n 8 /proc/meminfo; head -v -n 2 /proc/stat /proc/version /proc/
root        2867  0.0  0.0   2300   740 ?        S    15:54   0:00 sleep 30
ilovegym    2957  0.0  0.0   2300   676 ?        S    15:54   0:00 sleep 1
ilovegym    2958  0.0  0.0   7928  2760 pts/3    R+   15:54   0:00 ps -aux
ilovegym@VMC123-iobroker /opt/iobroker $ iobroker setup custom
Current configuration:
- Objects database:
  - Type: redis
  - Host/Unix Socket: 127.0.0.1
  - Port: 6379
- States database:
  - Type: redis
  - Host/Unix Socket: 127.0.0.1
  - Port: 6379

Type of objects DB [(f)ile, (r)edis, ...], default [redis]: jsonl
Host / Unix Socket of objects DB(jsonl), default[127.0.0.1]:
Port of objects DB(jsonl), default[9001]:
Type of states DB [(f)file, (r)edis, ...], default [jsonl]:
Host / Unix Socket of states DB (jsonl), default[127.0.0.1]:
Port of states DB (jsonl), default[9000]:
Data directory (file), default[../../iobroker-data/]:
Host name of this machine [VMC123-iobroker]:
It appears that you want to convert this slave host into a Master or Single host system. Is this correct? [Y/n]: y

Do you want to migrate objects and states from "redis/redis" to "jsonl/jsonl" [y/N]: y

Migrating the objects database will overwrite all objects! Are you sure that this is not a slave host and you want to migrate the data? [y/N]: y

Connecting to previous DB "redis"...

Cannot migrate DB while js-controller is still running!
Please stop ioBroker and try again. No settings have been changed.
ilovegym@VMC123-iobroker /opt/iobroker $ iobroker start

[AlCalzone]

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

Gibt es dahingehend Vorschläge oder Einschätzungen, wann welches Tool angebracht sein könnte?

Nach aktuellen Benchmarks hat JSONL etwas weniger Durchsatz als die File DB (obwohl die Tests auch etwas unfair sind, da File DB in fixen Abständen die komplette DB neu schreibt). JSONL hingegen schreibt nur Änderungen, dafür in Stoßzeiten ggf. häufiger.

Grundsätzlich würde ich sagen (JSONL vs. File):
JSONL ist resistenter. Ein kaputtes Byte in der DB macht nicht alles kaputt und ein Absturz beim Schreibvorgang sorgt nur dafür, dass die ausstehenden Änderungen verloren gehen, nicht alles.
JSONL schont die SD-Karte durch weniger und kleinere Schreibvorgänge (nur wenn nötig)
JSONL braucht zumindest phasenweise etwas mehr Platz (die DB ist bis auf Kompaktierungsvorgänge append-only)
JSONL braucht etwas länger, wenn viele Objekte in kurzer Zeit geschrieben werden sollen (wobei meine letzten Tests nur noch Unterschiede im Rahmen der Standardabweichung ergeben haben)

[apollon77]

@thomas-braun Am Ende geht es um den Durchsatz im System, welches primär CPU-basiert ist und um den I/O und RAM verbrauch (am Ende ein gewisses Dreieck der varianten).

Ich hatte es versucht mal grob in https://forum.iobroker.net/topic/26327/redis-in-iobroker-überblick anzudeuten, aber der aktuelle Stand wäre grob wie folgt (für eine DB Reinform -also Objects und States umgestellt):

• Redis: 20+% mehr Durchsatz weil optimierte Datenbank-Engine (und kein JavaScript); noch mehr wenn man States und Objects in zwei Redis-Prozesse trennt, da Redis auch grundsätzlich Single-threaded ist; I/O hängt sehr Stark davon ab wie man das ganze im Redis konfiguriert, da muss man echt aufpassen! Objects in Redis schliesst alle Files mit ein und benötigt so mehr RAM. Mit Redis kann man aber ggf in Richtung eines "anfänglichen HA Systems" gehen, weil hier da keine Master/Slave mehr gibt ind em Sinne ... die DB Zählt und hier kann Redis ein Cluster sein mit Sentinel.
• File-DB ist die Baseline was Durchsatz angeht quasi. I/O ist Mittelprächtig weil immer die ganzen tates/Objects-Daten auf einmal auf platte geschrieben werden - egal was sich geändert hat. Aber "Files" kosten kein RAM. Aber das System hat einen Master-Node - wenn der weg ist, ist alles offline.
• JSONL hat ggf. einen etwas geringeren Durchsatz weil regelmäßiger Daten gespeichert werden und hier und da Konsolidiert wird -am Ende aber weniger I/O. Und Files kosten auch kein RAM. Master-Node-Thema selbes wie File-DB

Bei File-DB und JSONL gilt das der js-controller diese DB bereitstellt was wieder Single-threaded ist.

Um ein Optimum zu finden (was aber noch keiner empirisch untersucht hat) kann man auch kombinieren. (Ich nutze bei meinen Redis Systemen zB bei States die RDB Persistenz und bei Objects AOF ... Formal hat auch bei JSONL noch keiner untersucht wie der I/O wirklich besser ist ... Bei Objects in jedem Fall ... für States bin ich nicht sicher)

Wer also eine optimierte I/O haben will der kann JSONL nutzen, was vor allem für SD Karten besser sein dürfte als "FileDB", die Berichte sind oben ... Objects in jedem Fall ... Geht aber ein bissl zu Lasten des Durchsatzes.

Wer Durchsatz optimieren will geht auf Redis, braucht aber ggf mehr RAM und muss die Persistenz einstellen.

Das "einfachste" ist aktuell File-DB und wenn wir JSONL zum Standard machen natürlich das Einfach weil wir schauen das wir die Limits sinnvoll einstellen das es irgendwie für alle passt ...

So lange der js-controller CPU Technisch nicht mehr als 60-70% braucht geht die Optimierung maximal um I/O ... und da sollte JSONL besser sein als File-DB. Wenn der controller mal "ständig" >70-80% hat und das anfängt den ioBroker in Summe langsamer zu machen dann kommt Redis ins Spiel ... vllt nur für die States oder so :-))

Und es gilt natürlich das was @AlCalzone gesagt hat

Hab ich genug Verwirrung gestiftet?

[crunchip]

@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

[apollon77]

@crunchip Hier sollte sich JSONL und File-DB nicht anders verhalten ... FileDB hat vllt sogar etwas weniger CPU-Last

[crunchip]

@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

[AlCalzone]

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.

[Ein ehemaliger Benutzer]

@apollon77

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"...

[apollon77]

@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 ... ... ...

[Ein ehemaliger Benutzer]

@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 ..

[apollon77]

@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?

[Ein ehemaliger Benutzer]

@apollon77

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..

[apollon77]

@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".

[Ein ehemaliger Benutzer]

@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.. :