@Negalein
Hab bis gerade mit dem technic Support dran gehangen.
Schein die push weg gewesen zu sein.
Aber ob es durch ein Server Update seitens Amazon war, habe ich nicht rausbekommen. Hoffe höre noch mehr dazu... wollten sich nochmal melden.
So schnell hat man 4 Std. Zeit investiert

pi@ioB:~$ free -ht --mega
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:       6,2G        3,7G        2,0G        3,3M        811M        2,5G
Swap:           1,0G          0B        1,0G
Gesamt:         7,2G        3,7G        3,0G
pi@ioB:~$

MOD-EDIT: Code in code-tags gesetzt!

Erstmal bis hierhin.
Seit dem letzten Post, wieder 1 GB RAM weiter benutzt.
Linux hin oder her... dann hätte der Arbeitspeicher auch unter Debian 10 so weglaufen müssen oder?
Liegt es hier an Debian 12 und an der Admin Version des IOB, dass die Ressourcen genutzt werden? Finde es prinzipiell gut... doch will es lediglich wenigstens verstehen, was es da macht.

Vielen Dank für die Unterstützung.

@paul53

kann ich verstehen, aber mit soivel RAM hätte ich nicht gerechnet.

Danke für Support

@thomas-braun

auch hier Danke für den Support. Habe Hubraum freigegeben

werde berichten

@homoran

Danke.

Werde mal schauen über die Tage und berichten.

Hallo Zusammen,

ich habe meinen ioB. vor ungefähr 2 Wochen neu aufgesetzt.
-> IOB ließ sich nicht mehr updaten und fix´n und dachte könnte direkt auf debain 12 aufrüsten.

Dabei eine VM (Synology VMM) mit Debian12 installiert.
VM_debian12: 1 CPU/6GB Ram (erstmal auf einen Kern)
Es ist NPM 9.8.1, Node 18.18.2, IOB 6.12.0 installiert.

Ich habe festgestellt, das der Arbeitsspeicher des Admin auf 300MB (dieser ganz extrem, ungefähr doppelter RAM) läuft sowie
diverse andere Adapter (KNX, JAVA, Ring, Tankekönig, etc) alle ungefähr 30% bis 50%
an Arbeitspeicher mehr benötigen, als im alten Vergleich System.
Habe zwar ein Error des Admin adapter, aber denke nicht, das der dafür verantwortlich ist.

"cannot call visUtils: Not exists" -> bei jeder Anmeldung am System

Den Vergleich konnte ich mit der alten VM erzielen, die ich noch als backup habe zum nachgucken.
VM_debian10: gleiche Einstellung wie oben
Dort ist NPM 8.18.0, Node 16.17.0, IOB 6.10.1 installiert.

Falls noch Angaben fehlen kann ich gerne nachliefern, aber vielleicht hat jemand einen Tipp für mich, was
ich machen kann oder wie welche Einstellung zu treffen sind um die Performance zu verbessern.

lg Ben

P.s.
nicht wundern, habe teilweise Adapter neu gestartet die dann erstmal bei 60-80 MB starten und dann über Tage hochlaufen im RAM.

@Negalein
Hab bis gerade mit dem technic Support dran gehangen.
Schein die push weg gewesen zu sein.
Aber ob es durch ein Server Update seitens Amazon war, habe ich nicht rausbekommen. Hoffe höre noch mehr dazu... wollten sich nochmal melden.
So schnell hat man 4 Std. Zeit investiert

@kaiserm
Bei mir ging es noch bis gestern Abend.
Heute morgen erst aufgefallen, das die rolladen nicht hoch fahren.
Ich glaube aber auch, das die push Funktion vom Server nicht automatisch läuft.
Denn ein händiger trigger im alexa2.0 Menü funktioniert. Könnte evtl. wenn alle strike reißen ein cron Befehl von jeder Sekunde setzen und müsste die blockly trigger auf "Änderung" anstatt "Aktualisierung" wieder stellen.
Hoffe auch das der sekündliche cron nicht Probleme seitens dem Server macht.
Finde es keine gute Lösung eigentlich, aber Abhilfe bis es vllt seitens Amazon wieder geht.

@Negalein
mich wundert es nur, das es einfach so über Nacht nicht mehr funktioniert.
Habe nämlich das Problem auch.

Kann man da jetzt auf Lösung hoffen, oder ist die summary Funktion jetzt hin?

Danke

LG Ben