EXPERIMENTELL: JsonL Datenbank für js-controller

[JLeg]

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

Das Setup des ioBrokers basiert darauf, dass es einen user iobroker gibt, der sehr fein abgestimmt gewisse Dinge tun darf oder auch nicht.

echt jetzt? "best practice" in allen Ehren, aber was wäre denn beim User iobroker "sehr fein abgestimmt", ausser dass sein Homedir bzw. Standarddir ihm gehört? Ich wüsste nicht, dass ACLs, apparmor- oder selinux-Templates in Gebrauch wären - oder Ähnliches... (?)

[Thomas Braun]

@jleg
Schau in die sudoers.
ACLs sind auch aktiv.

[JLeg]

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

@jleg
Schau in die sudoers.

Jo, damit werden Einschränkungen selektiv aufgehoben - wird aber durch "root"-Nutzung nicht unmittelbar "zerstört"...

ACLs sind auch aktiv.

bei mir offenbar nicht - klar sind ACLs "aktiv", ich zumindest sehe da aber nur das Standardmapping...

[Thomas Braun]

@jleg
Wenn man weiß was man tut...
Nur die meisten 'Ich bin root, weil ich das System nur so handeln kann'-User wissen es ja eben NICHT.
Und die Kombination 'relative Ahnungslosigkeit' und 'Ungefilterter Vollzugriff auf alles' ist halt denkbar ungünstig.

Die Tage war auch irgendein User hier unterwegs, mit gleich dreifacher Installation von node. Eine in /root, eine in /usr/local/bin und dann eine saubere. Halleluja, das funktioniert alles prima.

Ich bin z. B. auf meinem System noch nie in eine root-shell gewechselt. Wozu auch? Ich hab aber schon im falschen Verzeichnis einen falschen Befehl eingegeben. Als root wäre der durchgeschossen, als Standarduser ist nix passiert.

[JLeg]

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

@jleg
Wenn man weiß was man tut...
Nur die meisten 'Ich bin root, weil ich das System nur so handeln kann'-User wissen es ja eben NICHT.
Und die Kombination 'relative Ahnungslosigkeit' und 'Ungefilterter Vollzugriff auf alles' ist halt denkbar ungünstig.

stimmt natürlich - und ich sehe auch die "didaktische Strategie" - ich würd's halt nicht so dogmatisch rüberbringen wollen...

Die Tage war auch irgendein User hier unterwegs, mit gleich dreifacher Installation von node. Eine in /root, eine in /usr/local/bin und dann eine saubere. Halleluja, das funktioniert alles prima.

Ich bin z. B. auf meinem System noch nie in eine root-shell gewechselt. Wozu auch? Ich hab aber schon im falschen Verzeichnis einen falschen Befehl eingegeben. Als root wäre der durchgeschossen, als Standarduser ist nix passiert.

Erzähl' das einen Windowsuser - ich habe gehört, dass der Standarduser da zur Adminstratorengruppe gehört. Und UAC werden grundsätzlich weggeklickt. Also alles Gewohnheit...

[apollon77]

Leute ... root Diskussion bitte in nem anderen Thread

[msauer]

@apollon77 sagte

EIne Idee haben wir noch, Installiere die json pakete mal in /opt/iobroker (also nicht wie oben angegeben im /opt/ioborker/node_modules ...). Schau mal ob er es dann "behält".

Vllt will ja npm7 wieder anders behandelt werden.

Zu spät..,,hab komplett neu aufgesetzt und das Backup eingespielt. Schön mit Node 12 und NPM 6. Danach update JSONL und alles fluppt... Vielleicht doch ein kleiner Hinweis ganz oben, weil alles andere lief ja.

Dem Rest der Diskussion enthalte ich mich...wundere mich immer wieder nur...

[crunchip]

@alcalzone sagte in Test Javascript-Adapter 5.0.7 - RULES:

@crunchip Kannst du den CPU-Bedarf ggf. durch stoppen einzelner Adapter eingrenzen?

hab es mal hierher verschoben und bisserl probiert, zumindest sieht man einen "positiven" Einbruch der CPU beim Wled und Linux-control Adapter,
den fully-tablet-control hab ich mal deaktiviert(250mb Ram), gegen fullybrowser (56mb Ram)

Edit: fullytabletcontrol hat sich scheinbar aufgestaut im laufe der Zeit, nach wiederaktivieren 59mb Ram

wieder alles auf Ursprung

[AlCalzone]

@crunchip Ehrlich gesagt sieht linux-control relativ signifikant aus (fast 10% im Mittel). Aktualisiert der viele States oder schreibt der ggf. permanent seine Objekte neu?

[crunchip]

@alcalzone wie bereits erwähnt, hatte ich zuvor states-redis/objects-file und bei objects "writeFileInterval": 3600000 hinterlegt, da ich zuvor herausgefunden hatte, das wled einer der verantwortlichen Adapter ist, für das ständige neu schreiben der object.json,
seit dem lief alles sehr ruhig und die cpu lag im schnitt bei 15%.
Durchs ändern auf jsonl, stieg somit die cpu um mehr als das doppelt an, auf fast 35% im Scnitt.

dann kam das Phänomen mit den Rules dazu, was die Cpu nochmal um 10% ansteigen lies. ( was aktuell jedoch wieder zurück ging, nachdem kein Rules script mehr vorhanden ist)

richtig, linux control werden Massen an state's aktualisiert, weil ich dummerweise bei service nichts eingetragen habe und dadurch alle services einer angelegten Maschine hinterlegt werden, somit komme ich auf eine Gesamtanzahl von rund 10000 states, die im 60 sec intervall aktualisiert werden.
Müsste ich also ändern in der instanz und nur explizite services auswählen, die ich haben möchte und den Rest löschen.

Dennoch bleibt aber der massive CPU Unterschied von redis zu jsonl mit aktueller Konstellation.

Ich habe auch noch weitere Adapter mit sehr vielen state's wie z.b.
unifi, sourceanalytics, sonoff, coronavirus-statistics, daswetter

daswetter habe ich z.b schon seit nem dreiviertel Jahr deaktiviert, da es ebenfalls für einen enormen CPU Anstieg gesorgt hatte.

Edit:
Habe jetzt die services iin der Instanz angepasst, durch speichern und schließen der Instanz, werden die "überflüssigen" Datenpunkte automatisch gelöscht. Dabei ist der simple api mehrmals abgestürzt. Das Problem kenne ich schon länger, bisher konnte mir aber niemand eine Antwort darauf geben, warum das passiert.
Nutze daher dies sogleich, es hier nochmal zu erwähnen, das dies hin und wieder passiert, wenn man, ich nenne es mal "zu viele Datenpunkte auf einmal löscht". siehe Log, das ganze ist insgesamt dreimal passiert.
Gegebenenfalls kann ich auch diesbezüglich einen neuen Thread eröffnen.

host.IoBroker	2021-03-03 23:01:44.496	info	instance system.adapter.simple-api.0 started with pid 12996
host.IoBroker	2021-03-03 23:01:22.611	info	instance system.adapter.weatherunderground.0 terminated with code 0 (NO_ERROR)
host.IoBroker	2021-03-03 23:01:14.391	info	Restart adapter system.adapter.simple-api.0 because enabled
host.IoBroker	2021-03-03 23:01:14.389	error	instance system.adapter.simple-api.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
host.IoBroker	2021-03-03 23:01:14.388	error	Caught by controller[0]: at processTicksAndRejections (internal/process/task_queues.js:97:5)
host.IoBroker	2021-03-03 23:01:14.387	error	Caught by controller[0]: at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/@iobroker/db-objects-jsonl/node_modules/@iobroker/db-objects-redis/lib/objects/ob
host.IoBroker	2021-03-03 23:01:14.386	error	Caught by controller[0]: TypeError: Cannot read property 'common' of null
host.IoBroker	2021-03-03 23:01:14.383	error	Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejecte
simple-api.0	2021-03-03 23:01:13.793	info	(31766) terminating with timeout
simple-api.0	2021-03-03 23:01:12.290	warn	(31766) Terminated (UNCAUGHT_EXCEPTION): Without reason
simple-api.0	2021-03-03 23:01:12.283	info	(31766) terminating
simple-api.0	2021-03-03 23:01:12.280	info	(31766) terminating http server on port 8087
simple-api.0	2021-03-03 23:01:12.122	error	(31766) Cannot read property 'common' of null
simple-api.0	2021-03-03 23:01:12.121	error	at processTicksAndRejections (internal/process/task_queues.js:97:5)
simple-api.0	2021-03-03 23:01:12.121	error	at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/@iobroker/db-objects-jsonl/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:3607
simple-api.0	2021-03-03 23:01:12.121	error	(31766) TypeError: Cannot read property 'common' of null
simple-api.0	2021-03-03 23:01:12.084	error	(31766) unhandled promise rejection: Cannot read property 'common' of null
simple-api.0	2021-03-03 23:01:12.053	error	(31766) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
host.IoBroker	2021-03-03 23:00:26.927	info	instance system.adapter.ical.0 terminated with code 0 (NO_ERROR)
host.IoBroker	2021-03-03 23:00:26.089	info	instance system.adapter.linux-control.0 started with pid 12441
host.IoBroker	2021-03-03 23:00:23.762	info	instance system.adapter.linux-control.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
host.IoBroker	2021-03-03 23:00:22.769	info	stopInstance system.adapter.linux-control.0 send kill signal
host.IoBroker	2021-03-03 23:00:22.576	info	stopInstance system.adapter.linux-control.0 (force=false, process=true)

[AlCalzone]

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

für das ständige neu schreiben der object.json,
seit dem lief alles sehr ruhig und die cpu lag im schnitt bei 15%.
Durchs ändern auf jsonl, stieg somit die cpu um mehr als das doppelt an, auf fast 35% im Scnitt.

Das macht für mich Sinn. JSONL merkt sich jede Änderung und dedupliziert dann erst beim Komprimieren. Das heißt aber auch, dass jede dieser Objekt-Änderungen ein JSON.stringify verursacht, dessen Ergebnis dann bis zum nächsten Schreibvorgang im Puffer landet. Wenn das ständig passiert, erzeugt das schon ordentlich Last, da Objekte deutlich mehr Arbeit fürs stringify bedeuten als einfache States.
objects-file hat die unnötigen Änderungen einfach im Speicher überschrieben und dann einmal beim Rausschreiben stringified.
Ggf. könnte hier auch noch ein wenig schlauer gearbeitet werden - ich mach mir mal ein Issue zum Experimentieren.

Wäre ggf. dennoch einen Versuch wert, die Verursacher mal etwas zu gängeln, das dauerhafte Schreiben abzustellen.

[MalleRalle]

Moin @ All
Bevor ich das mal teste.
Wie wird die Datenbank denn gesichert?
Wird die bei einem normalen Backup z.B. über Backitup mit gesichert?

[apollon77]

@malleralle Ja

[crunchip]

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

Ggf. könnte hier auch noch ein wenig schlauer gearbeitet werden - ich mach mir mal ein Issue zum Experimentieren.

Gibt es schon neue Erkenntnisse/Fortschritte?

[apollon77]

Es gibt ab jetzt den neuen js-controller 3.3 im Latest (https://forum.iobroker.net/topic/44624/js-controller-3-3-jetzt-im-latest) ... Bei Nutzung einer JSONL-Datenbank sollte das Update nach bisherigen Tests problemlos funktionieren ... Falls nicht bitte lasst uns das hier diskutieren.

Bitte in JEDEM FALL ein Backup vorher haben!

[msauer]

Hi. Wie sehe ich eigentlich, welche Version von JSONL ich aktuell einsetze und wenn, wie mache ich einen Update?

[apollon77]

@msauer Das ist nur relevant mit js-controller 3.2 und hier sollte es jsonl@1.1.x sein. Ab js-controller 3.3 kommen die Libraries schon mit dem Controller mit.

Sehen der Version geht per npm ls --all |grep "iobroker/db"

[msauer]

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

Sehen der Version geht per npm ls --all |grep "iobroker/db"

Ausgabe des Commands ist leer!?

[apollon77]

@msauer Ausgeführt in /opt/iobroker ??

[msauer]

@apollon77 Natürlich nicht. ... mea culpa