EXPERIMENTELL: JsonL Datenbank für js-controller
-
@apollon77 jsonL läuft bei mir schon sei 14.Feb., siehe https://forum.iobroker.net/post/581193 und folgende
was ich gerade getan hab
iobroker stop
iobroker updatemehr hab ich nicht gemacht
-
@crunchip Und dann hast Du ein controller 3.3 update gemacht oder noch nicht?
Was sagt im ioBroker Verzeichnis
npm ls --all |grep "iobroker/db" -
@apollon77 hab ich nicht gemacht, iobroker wieder gestartet, wollte mich lieber vorher versichern bzw nachfragen
root@IoBroker:/opt/iobroker# npm ls --all |grep "iobroker/db" npm ERR! extraneous: @types/request@2.48.1 /opt/iobroker/node_modules/@types/request npm ERR! extraneous: alcalzone-shared@2.3.0 /opt/iobroker/node_modules/alcalzone-shared npm ERR! extraneous: alexa-remote2@2.5.3 /opt/iobroker/node_modules/alexa-remote2 npm ERR! extraneous: anyproxy@4.1.0 /opt/iobroker/node_modules/anyproxy npm ERR! extraneous: bottleneck@2.19.2 /opt/iobroker/node_modules/bottleneck npm ERR! extraneous: castv2-player@2.0.5 /opt/iobroker/node_modules/castv2-player npm ERR! extraneous: coffee-compiler@0.3.2 /opt/iobroker/node_modules/coffee-compiler npm ERR! extraneous: coffee-script@1.12.7 /opt/iobroker/node_modules/coffee-script npm ERR! extraneous: express-fileupload@0.4.1 /opt/iobroker/node_modules/express-fileupload npm ERR! extraneous: iobroker-react-components@1.0.0 /opt/iobroker/node_modules/iobroker-react-components npm ERR! extraneous: js2xmlparser@3.0.0 /opt/iobroker/node_modules/js2xmlparser npm ERR! extraneous: mongodb@3.2.7 /opt/iobroker/node_modules/mongodb npm ERR! extraneous: node-hue-api@2.4.6 /opt/iobroker/node_modules/node-hue-api npm ERR! extraneous: node-inspect@2.0.0 /opt/iobroker/node_modules/node-inspect npm ERR! extraneous: node-red@0.20.7 /opt/iobroker/node_modules/node-red npm ERR! extraneous: node-red-contrib-aggregator@1.5.0 /opt/iobroker/node_modules/node-red-contrib-aggregator npm ERR! extraneous: node-red-contrib-os@0.1.7 /opt/iobroker/node_modules/node-red-contrib-os npm ERR! extraneous: node-red-contrib-polymer@0.0.21 /opt/iobroker/node_modules/node-red-contrib-polymer npm ERR! extraneous: node-red-dashboard@2.15.5 /opt/iobroker/node_modules/node-red-dashboard npm ERR! extraneous: portfinder@1.0.20 /opt/iobroker/node_modules/portfinder npm ERR! extraneous: rpi-gpio@2.1.3 /opt/iobroker/node_modules/rpi-gpio npm ERR! extraneous: sync-exec@0.6.2 /opt/iobroker/node_modules/sync-exec npm ERR! extraneous: systeminformation@4.14.4 /opt/iobroker/node_modules/systeminformation npm ERR! extraneous: typescript@3.5.1 /opt/iobroker/node_modules/typescript npm ERR! extraneous: virtual-device-sdk@1.5.18 /opt/iobroker/node_modules/virtual-device-sdk npm ERR! extraneous: virtual-tsc@0.6.1 /opt/iobroker/node_modules/virtual-tsc npm ERR! extraneous: vm2@3.8.1 /opt/iobroker/node_modules/vm2 npm ERR! extraneous: wake_on_lan@1.0.0 /opt/iobroker/node_modules/wake_on_lan npm ERR! extraneous: zigbee-herdsman-converters@14.0.110 /opt/iobroker/node_modules/zigbee-herdsman-converters npm ERR! extraneous: zigbee-shepherd@0.3.0 /opt/iobroker/node_modules/zigbee-shepherd npm ERR! extraneous: zigbee-shepherd-converters@10.1.9 /opt/iobroker/node_modules/zigbee-shepherd-converters npm ERR! extraneous: @alcalzone/release-script@1.8.3 /opt/iobroker/node_modules/iobroker.javascript/node_modules/@alcalzone/release-script npm ERR! extraneous: chai@4.3.4 /opt/iobroker/node_modules/iobroker.javascript/node_modules/chai npm ERR! extraneous: del@6.0.0 /opt/iobroker/node_modules/iobroker.javascript/node_modules/del npm ERR! extraneous: eslint@7.23.0 /opt/iobroker/node_modules/iobroker.javascript/node_modules/eslint npm ERR! extraneous: gulp@4.0.2 /opt/iobroker/node_modules/iobroker.javascript/node_modules/gulp npm ERR! extraneous: gulp-rename@2.0.0 /opt/iobroker/node_modules/iobroker.javascript/node_modules/gulp-rename npm ERR! extraneous: gulp-replace@1.0.0 /opt/iobroker/node_modules/iobroker.javascript/node_modules/gulp-replace npm ERR! extraneous: mocha@8.3.2 /opt/iobroker/node_modules/iobroker.javascript/node_modules/mocha npm ERR! extraneous: timekeeper@2.2.0 /opt/iobroker/node_modules/iobroker.javascript/node_modules/timekeeper npm ERR! peer dep missing: date-fns@^2.0.0, required by @date-io/date-fns@1.3.13 npm ERR! peer dep missing: @material-ui/core@^4.0.0, required by @material-ui/pickers@3.2.10 npm ERR! peer dep missing: react@^16.8.4, required by @material-ui/pickers@3.2.10 npm ERR! peer dep missing: react-dom@^16.8.4, required by @material-ui/pickers@3.2.10 npm ERR! peer dep missing: react@>=16.6.0, required by react-transition-group@4.4.1 npm ERR! peer dep missing: react@>=16.8, required by rifm@0.7.0 npm ERR! peer dep missing: react-dom@>=16.6.0, required by react-transition-group@4.4.1 │ ├─┬ @iobroker/db-objects-file@1.1.4 │ │ ├─┬ @iobroker/db-base@1.1.4 │ │ ├── @iobroker/db-objects-redis@1.1.4 deduped │ ├─┬ @iobroker/db-objects-jsonl@1.1.5 │ │ ├─┬ @iobroker/db-base@1.1.4 │ │ ├─┬ @iobroker/db-objects-file@1.1.4 │ │ │ ├── @iobroker/db-base@1.1.4 deduped │ │ │ ├── @iobroker/db-objects-redis@1.1.4 deduped │ │ ├─┬ @iobroker/db-objects-redis@1.1.4 │ │ │ ├── @iobroker/db-base@1.1.4 deduped │ ├─┬ @iobroker/db-objects-redis@1.1.4 │ │ ├── @iobroker/db-base@1.1.4 deduped │ ├─┬ @iobroker/db-states-file@1.1.4 │ │ ├── @iobroker/db-base@1.1.4 deduped │ │ └── @iobroker/db-states-redis@1.1.4 deduped │ ├─┬ @iobroker/db-states-jsonl@1.1.5 │ │ ├── @iobroker/db-base@1.1.4 deduped │ │ ├─┬ @iobroker/db-states-file@1.1.4 │ │ │ ├── @iobroker/db-base@1.1.4 deduped │ │ │ └── @iobroker/db-states-redis@1.1.4 deduped │ │ └─┬ @iobroker/db-states-redis@1.1.4 │ │ ├── @iobroker/db-base@1.1.4 deduped │ ├─┬ @iobroker/db-states-redis@1.1.4 │ │ ├── @iobroker/db-base@1.1.4 deduped root@IoBroker:/opt/iobroker# -
@crunchip Na dann bin ich erstmal bei der Annahme das es an dem liegt was einige User schonmal hatten: Editiere mal in der iobroker.json das "connectTimeout" unter states und objects und seite es auf 10000
-
@apollon77 sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:
das "connectTimeout" unter states und objects und seite es auf 10000
das gibts bei mir nur unter objects?
"objects": { "type": "jsonl", "typeComment": "Possible values: 'file' - [port 9001], redis - [port 6379], couch - [port 5984].", "host": "127.0.0.1", "port": 9001, "user": "", "pass": "", "noFileCache": false, "connectTimeout": 10000, "dataDir": "../../iobroker-data/", "options": { "auth_pass": null, "retry_max_delay": 5000 } }, "states": { "type": "jsonl", "typeComment": "Possible values: 'file' - [port 9000], 'redis' - [port 6379].", "host": "127.0.0.1", "port": 9000, "maxQueue": 1000, "options": { "auth_pass": null, "retry_max_delay": 5000 }, "dataDir": "../../iobroker-data/" -
@crunchip Kannst es bei states mit einfügen,aber denke ist eh am relevantesten bei Objects
-
@apollon77 ok, mach ich und teste mal
-
@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 -
@crunchip Ja beim ersten update von <3.3 auf 3.3 passiert das. danach nicht mehr. das timeout kann wieder runtergesetzt werden
-
@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... -
@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.
-
@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?
-
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 -
@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) -
@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?
-
@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"...
