das sieht dann doch nach Memory leak aus, oder was meint ihr?

Kann an denn irgendwie feststellen, wo der Arbeitsspeicher aufgefressen wird?

Vielen Dank!

da wurde es so gemacht

Geht natürlich auch so, aber das "sonst" oder "sonst falls" kann man sich dann sparen. Ist aber nur als Beispiel zu verstehen. Skripte können miese Bazillen sein kenn ich aus eigener Erfahrung

Ich habe jetzt immer nach dem Timeout eine sonst mit stop Timeout eingesetzt!?

Nicht ganz. Besser wäre (ist ein Beispiel):

Nach dem Trigger erstmal den Timeout stoppen und dieser Timeout wird dann nach "falls" ausgeführt.

Zusätzlich habe ich alle meine Scripts durchgesehen und die Timeouts bearbeitet. Ich hoffe, dass ich das auch richtig verstanden hab. Ich habe jetzt immer nach dem Timeout eine sonst mit stop Timeout eingesetzt!?

https://forum.iobroker.net/topic/42792/javascript-heap-out-of-memory-workaround

Hallo,
seit heute geht der javascript adapter immer von grün auf rot.

Was ist hiermit :

@thomas-braun sagte in Javascript adapter geht immer von grün auf rot:
@djsirius sagte in Javascript adapter geht immer von grün auf rot:

Aktualisierung für 16 Pakete verfügbar.

System auf Stand halten.
Im Log File steht was genau, wenn der Adapter (Neu)gestartet wird?

Mit

iobroker logs --watch

beobachten.

und zeige mal was du hast

habe heute updates gemacht, und ich meine, dass der javascript adapter auch ein update bekommen hat.

ich bin bei allen Adaptern auf dem aktuellen Stand.

BETA !???

iobroker update -i
iobroker list instances 

Vielen Dank!

Aktualisierung für 16 Pakete verfügbar.

System auf Stand halten.
Im Log File steht was genau, wenn der Adapter (Neu)gestartet wird?

Mit

iobroker logs --watch

beobachten.

uname -m && which nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs

iobroker@debian:~$ sudo ln -s /usr/bin/node /usr/bin/nodejs
ln: die symbolische Verknüpfung '/usr/bin/nodejs' konnte nicht angelegt werden: Die Datei existiert bereits
iobroker@debian:~$ uname -m && which nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs
x86_64
/usr/bin/nodejs
/usr/bin/node
/usr/bin/npm
v14.19.3
v14.19.3
6.14.17
iobroker
/home/iobroker
OK:1 http://deb.debian.org/debian buster InRelease
OK:2 http://security.debian.org/debian-security buster/updates InRelease
OK:3 http://deb.debian.org/debian-security buster/updates InRelease
OK:4 http://deb.debian.org/debian buster-updates InRelease
OK:5 http://deb.debian.org/debian buster-backports InRelease
OK:6 http://ftp.de.debian.org/debian buster InRelease
OK:7 https://packages.sury.org/php buster InRelease
OK:8 https://deb.nodesource.com/node_14.x buster InRelease
OK:9 http://ftp.de.debian.org/debian buster-updates InRelease
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Aktualisierung für 16 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.
nodejs:
  Installiert:           14.19.3-deb-1nodesource1
  Installationskandidat: 14.19.3-deb-1nodesource1
  Versionstabelle:
 *** 14.19.3-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_14.x buster/main amd64 Packages
        100 /var/lib/dpkg/status
     10.24.0~dfsg-1~deb10u1 500
        500 http://ftp.de.debian.org/debian buster/main amd64 Packages
        500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
        500 http://deb.debian.org/debian buster/main amd64 Packages
        500 http://deb.debian.org/debian-security buster/updates/main amd64 Packages
iobroker@debian:~$ free -ht --mega
              total        used        free      shared  buff/cache   available
Mem:           7,9G        2,7G        3,9G         13M        1,2G        4,9G
Swap:          4,0G          0B        4,0G
Total:          11G        2,7G        7,9G
iobroker@debian:~$

Ein beliebter Fehler sind die Timer

Ja, das war bei mir auch mal das Problem und Dank @paul53 und seinem Blockly-Wissen habe ich alle meine Skripte mit Timern geradegebogen.

Das entstehen von Memory leaks hat etwas mit dem automatischen Speicher Management von JavaScript und der fehlerhaften Anwendung von bestimmten Mustern zu tun
Ein beliebter Fehler sind die Timer
Du erzeugst mit onIntervsl oder onTimeout einen Timer.
Du erhältst eine id zurück mit der du diesen Timer wieder löschen kannst. Geht dir dieser verloren oder wird das Skript neu gestartet, dann existiert dieser Timer im Speicher immer noch ohne Möglichkeit den zu löschen (nur Neustart des Ja Adapters hilft hier)
Wenn jetzt diese Stelle zig Fach aufgerufen wird, dann sammelt sich dieser Müll im Speicher an und frisst deinen freien Speicher für diesen thread (nennt sich heap) weg.
Das selbe gilt auch für trigger (insbesondere trigger in trigger)

Schau rein, ob die Basis sauber ist.

sudo ln -s /usr/bin/node /usr/bin/nodejs
uname -m && which nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs

free -ht --mega

ich bin bei allen Adaptern auf dem aktuellen Stand.

Aber woher kommt das mit dem Memory leak auf einmal her kommen.

Was komisch ist, dass der Adapter auf der vorherigen Version stabil läuft.

Memory leak werde ich mir aber mal ansehen.

Vielen Dank für den Tipp!

aber zur sicherheit auf jedenfall mal das log hier übermitteln, wie thomas geschrieben hat.

ich habe schon den debug mode angeschlatet, aber leider bekomme ich keine fehlermeldung.

aberirgendwaswirdwohldaimlogerscheinen
welcheversionensindinstalliert?allesaufstand?