Javascript Adapter rot (out of memory)
-
Hi,
seit 3 Tagen funktioniert mein Zusammenspiel zwischen iobroker und pivccu nicht mehr korrekt. Evtl. liegt es auch an den Blockly Regeln. Denn im Log finde ich folgenden Fehler. Auch ist der Javascript Adapter immer wieder rot.
Das Konstrukt läuft auf einem pi4 mit 2gb RAM. 1 gb davon ist noch frei.
Alle Adapter sind auf aktuellstem Stand.Node.js: v10.19.0
NPM: 6.13.4Habt ihr eine Idee?
host.iobroker 2020-05-07 08:01:52.376 info Restart adapter system.adapter.javascript.0 because enabled host.iobroker 2020-05-07 08:01:52.375 info instance system.adapter.javascript.0 terminated with code NaN () host.iobroker 2020-05-07 08:01:52.375 warn instance system.adapter.javascript.0 terminated due to SIGABRT host.iobroker 2020-05-07 08:01:52.374 error Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory host.iobroker 2020-05-07 08:00:38.684 info instance system.adapter.shelly.0 started with pid 2519 host.iobroker 2020-05-07 08:00:08.670 info Restart adapter system.adapter.shelly.0 because enabled host.iobroker 2020-05-07 08:00:08.669 info instance system.adapter.shelly.0 terminated with code 0 (NO_ERROR) host.iobroker 2020-05-07 08:00:05.985 info instance system.adapter.daswetter.0 terminated with code 0 (NO_ERROR) host.iobroker 2020-05-07 08:00:00.026 info instance system.adapter.daswetter.0 started with pid 2481 -
@maxpd
Auf welchem System fährst du da?
Linux?free -m top who -r -
-
@maxpd Bitte keine Screenshots sondern die Ausgaben als Text in Code-Tags setzen. Wenn du per SSH auf der Kiste bist:
sudo init 3 -
Ok, was bei Top rauskommt über Putty, kann ich nicht kopieren. Danach kann ich auch in Putty nichts mehr machen.
sudo init 3 scheint keinen Effekt zu haben. Es passiert zumindest nichts, ich lande nur in einer neuen Zeile.
-
@maxpd
Wiederhole die Befehle von oben.
Aus top kommst du mit Strg-C raus -
pi@iobroker:~ $ free -m total used free shared buff/cache available Mem: 1939 804 961 4 173 1052 Swap: 99 6 93 pi@iobroker:~ $ top top - 08:45:20 up 51 min, 1 user, load average: 0.16, 0.13, 0.13 Tasks: 152 total, 1 running, 151 sleeping, 0 stopped, 0 zombie %Cpu(s): 13.2 us, 5.9 sy, 0.0 ni, 80.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 1939.4 total, 961.5 free, 804.6 used, 173.3 buff/cache MiB Swap: 100.0 total, 94.0 free, 6.0 used. 1052.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 493 iobroker 20 0 250416 145628 25620 S 31.2 7.3 3:57.58 iobroker.+ 1254 iobroker 20 0 149908 48252 25660 S 12.5 2.4 0:08.73 io.hm-reg+ 1526 root 20 0 30316 12972 3972 S 6.2 0.7 0:02.69 ReGaHss.c+ 1657 iobroker 20 0 148532 45084 25692 S 6.2 2.3 0:04.98 io.sonoff+ 2588 iobroker 20 0 195744 92500 25672 S 6.2 4.7 0:34.80 io.javasc+ 4462 pi 20 0 10320 2908 2544 R 6.2 0.1 0:00.02 top 1 root 20 0 33728 7652 6388 S 0.0 0.4 0:01.60 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.51 kworker/0+ 7 root 20 0 0 0 0 I 0.0 0.0 0:00.22 kworker/u+ 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu+ 9 root 20 0 0 0 0 S 0.0 0.0 0:00.17 ksoftirqd+ 10 root 20 0 0 0 0 I 0.0 0.0 0:01.18 rcu_sched 11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh 12 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration+ pi@iobroker:~ $ who -r run-level 3 2020-05-07 08:36 last=5 pi@iobroker:~ $ sudo init 3 pi@iobroker:~ $ -
-
pi@iobroker:~ $ free -m total used free shared buff/cache available Mem: 1939 825 939 5 174 1031 Swap: 99 6 93 pi@iobroker:~ $ top top - 09:07:55 up 1:13, 1 user, load average: 0.18, 0.13, 0.12 Tasks: 158 total, 1 running, 157 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 2.9 sy, 0.0 ni, 97.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 1939.4 total, 940.6 free, 824.3 used, 174.6 buff/cache MiB Swap: 100.0 total, 94.0 free, 6.0 used. 1032.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5443 pi 20 0 10324 2848 2484 R 6.2 0.1 0:00.02 top 1 root 20 0 33728 7660 6388 S 0.0 0.4 0:01.75 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.56 kworker/0+ 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu+ 9 root 20 0 0 0 0 S 0.0 0.0 0:00.21 ksoftirqd+ 10 root 20 0 0 0 0 I 0.0 0.0 0:01.58 rcu_sched 11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh 12 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration+ 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1 15 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration+ 16 root 20 0 0 0 0 S 0.0 0.0 0:00.13 ksoftirqd+ 17 root 20 0 0 0 0 I 0.0 0.0 0:00.66 kworker/1+ 19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2 pi@iobroker:~ $ who -r run-level 3 2020-05-07 08:36 last=5 pi@iobroker:~ $ sudo init 3 pi@iobroker:~ $ free -m total used free shared buff/cache available Mem: 1939 825 939 5 174 1031 Swap: 99 6 93 pi@iobroker:~ $Aber da ist doch viel frei?
-
node -v nodejs -v npm -v which node which nodejs which npm -
pi@iobroker:~ $ node -v v10.19.0 pi@iobroker:~ $ nodejs -v v10.19.0 pi@iobroker:~ $ npm -v 6.13.4 pi@iobroker:~ $ which node /usr/bin/node pi@iobroker:~ $ which nodejs /usr/bin/nodejs pi@iobroker:~ $ which npm /usr/bin/npm -
@maxpd Die Error-Zeile ganz oben aus dem Log sagt doch eigentlich, was los war. Dem Javascript-Adapter ging, zumindest temporär, der Speicher aus. Daraufhin wurde er neu gestartet und der Speicher war erstmal wieder frei.
Läuft da irgendein aufwändiges Script oder vielleicht eines, welches irgendwelche verschachtelten Loops startet oder Ähnliches?
Gruss, Jürgen
-
curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash - sudo apt update sudo apt dist-upgrade -
Zuletzt gearbeitet habe ich an dem hier.
in die grüne Schleife ist er bislang noch nicht reingelaufen. Ansonsten ist es ja ziemlich simpel.
und
Scripte habe ich 30 oder so laufen.
-
@maxpd
Bei node 12 hat sich wohl was geändert, wie mit dem heap umgegangen wird. Vielleicht bringt der Spung auf ein node > 10 was. -
@Thomas-Braun danke dir. Habe ein Update gemacht. Werde mal abwarten müssen.
-
@maxpd sagte:
in die grüne Schleife ist er bislang noch nicht reingelaufen.
Bist Du sicher ? Es ist wahrscheinlich genau diese Endlos-Schleife, die "out of memory" erzeugt.
-
der Rollladen ist bislang noch nie auf eine Höhe von 55% hinsichtlich der Regeln. Von daher nehme ich es an.
Wie regelt man es besser? Neuer Trigger bei Azimut 130? -
@maxpd
Von der Java-Diskussion abgesehen wäre es vermutlich eine gute Idee den kleinen Raspi im runlevel 3 (ohne graphische Oberfläche) zu betreiben. -
@Thomas-Braun die Oberfläche dann über einen 2. Raspi darstellen? Denn brauchen tu ich sie unbedingt.
