Admin, Influx und Javascript.. Nodejs - Memory Limits?

[Thomas Braun]

@ilovegym sagte in Admin, Influx und Javascript.. Nodejs - Memory Limits?:

das update hab ich mit dem command "iob nodejs-update 20"gemacht..

[apollon77]

Also auch uns kommt das komisch vor. ich verstehe nicht warum Admin beim aufklappen so viel RAM braucht ... @foxriver76 schaut mal rein

[Neuschwansteini]

@apollon77 @foxriver76

Danke schonmal! Ich hatte ja vor ein paar Monaten noch viel mehr States und Objects, waren ueber 130000, mit Node 18 und js-controller 4.x und die ersten Admin V6.x.. da lief das ja alles, war in einem Bullseye LXC installiert, Redis auch extern in einem LXC.
Hatte dann auf js-controller 5.x Alpha geupdated und irgendwann fingen die Probleme mit dem Backup an, dass so alles lief, aber beim iob backup der OOM kam.. das hatten wir damals behoben.. und seitdem habe ich auch die Objects und States reduziert, weil wir ja dachten, es liegt daran..

Hatte dann mit dem Release von js-controller 5.x ne VM mit Bookworm aufgesetzt, und das Backup eingespielt..
Seitdem frisst der Admin viel mehr.. Vergleichbar ist das alles nicht, da damals andere Versionen von Admin usw. ja installiert waren..

Habe gestern dann auf Node 20 hochgezogen, was Problemlos durchlief und nach nem Reboot laeuft auch alles. Insgesamt ist der benutzte Ram etwas weniger, im Schnitt jetzt bei 9,9GB, vorher mit Node18 war er bei 11GB.
Es sind sonst keine Updates gemacht worden.
Habe jetzt bei Admin nix drin stehen, beim Ram, nur bei Influx 8192, und bei Javascript 4096, das laeuft bis jetzt auch alles ohne Fehler. Die gesamte VM hat 64Gb Ram. Habe seitdem auch das Ballooning aus, vielleicht war da auch der Wurm drin.. dass er keine 4GB Ram am Stueck hatte.. hmpff alles schwer nachzuvollziehen...

[apollon77]

@ilovegym Schau mal ob sich Admin 6.12.0 wad den RAM verbrauch angeht anders verhält

[Neuschwansteini]

@apollon77

leider nicht, sieht genauso aus:

[Neuschwansteini]

@apollon77 sagte in Admin, Influx und Javascript.. Nodejs - Memory Limits?:

@ilovegym Schau mal ob sich Admin 6.12.0 wad den RAM verbrauch angeht anders verhält

so, etwas rumgespielt... im Objektbrowser hat sich einiges getan, hier kann ich endlich meine Sonoff (7800 Objekte ) und Zigbee (2600) exportieren, das hat vorher nicht geklappt, kam kein Fehler, ging einfach nicht.. jetzt gehts. Super!

Dann, ich habe mal etliche Objekte (7600) am Stueck aus der History raus genommen, da hat er sich vorher im Memory hochgeschaukelt bis OOM kam... das klappt jetzt! Super!
Also auf jeden Fall verbessert !

[apollon77]

@ilovegym Der Dank geht voll an @foxriver76

[Neuschwansteini]

@apollon77 @apollon77 @arteck

sooo hab was gefunden, wegen hohem Ram Verbrauch von Admin, Influx und Javascript.. und OOM beim Backup.....!!

es war KEINS der 727 Scripte, die laufen...

Es haengt zusammen mit dem Objektbrowser vom Admin-Adapter, ich hatte mir immer einige Objektbaeume exportiert und im neuen iobroker dann importiert, um nicht alle 3000 Objecte vom Zigbee-Adapter mit Raeumen und Funktionen und Beschreibungen der Objekte neu erstellen zu muessen.
Also im alten iobroker den Baum exportiert, hier hatte ich meist userdata.0., javascript.0, alias, sonoff, tuya und zigbee gebraucht, und dann diese wieder importiert..

Das hat auch immer ohne Fehler geklappt, danach lief aber der Ram im Admin schon hoch.. und wenn ich jetzt noch ein paar Objekte wegen Influx markieren wollte... dann war's vorbei..
Das ist nachvollziehbar, ich hab die letzten 2 Wochen bestimmt 12 neue iobroker-Systeme (lxc, vm, docker) neu aufgesetzt, mit Redis als lxc, Redis im iobroker, und jsonl.. weil ich dachte, da haengts.. nee

Wenn ich mir die exportierten Objekte so betrachte, dann sind da auch Eintraege von Adaptern drin, die eigentlich beim De-Installieren geloescht werden sollten..
zum Beispiel Influx.1., Lightcontrol, SQL.. habe auf dem Testsystem auch ne zweite Influx Instanz installiert, und geloescht, er fragt ja, ob alle Eintraege geloescht werden sollen, jaaa.. solllen sie.. macht er aber nicht...

Jetzt ist die Frage.. ist das ein Fehler von Admin, oder ein Fehler von Influx? Da auch SQL (den Lightcontrol hatte ich als Beta, den lassen wir mal weg.. ) noch drin steht.. denke ich nicht, dass alle Adapter da einen Fehler haben.. denke eher, das ist was von Admin oder js-controller?
Wer loescht den Kram aus den Objekten?

irgendeine Idee ? Ich leg gern ein Issue an und stell den kaputten Objects zur Verfuegung, falls sich jemand sein System schiessen mag..

[apollon77]

@ilovegym Also exportiert er zuviel? Oder wie? Ichverstehe das Thema noch nicht ganz - auch weil er dann ja diese hohe menge an Objekten und so auch anzeigen sollte nach dem reimport

[Neuschwansteini]

@apollon77

Irgendwo muss mir was mal die objects geschossen haben, und das hab ich rum geschleppt.

Dazu kommt noch, dass bei deinstall eines Adapters die assignments nicht gelöscht, obwohl der Haken gesetzt war..

[A Former User]

@ilovegym sagte in Admin, Influx und Javascript.. Nodejs - Memory Limits?:

Dazu kommt noch, dass bei deinstall eines Adapters die assignments nicht gelöscht, obwohl der Haken gesetzt war..

Moin,

@ilovegym sagte in Admin, Influx und Javascript.. Nodejs - Memory Limits?:

Also im alten iobroker den Baum exportiert, hier hatte ich meist userdata.0., javascript.0, alias, sonoff, tuya und zigbee gebraucht, und dann diese wieder importiert..

Nur so zu meinem Verständnis, Du betreibst doch ioBroker mit Redis, ist das dann der korrekte weg, mit Export und Import?

VG
Bernd

[apollon77]

@dp20eic Warum nicht? Das ist der "User convenient way" mit ner UI