NEWS
[gelöst] Speicherleck? Memory Leak?
-
Hallo,
nachdem ich zur Einbindung der MySensors Technik auch den mqtt und node-red Adapter installiert habe, wurde mein System instabil. D.h. es kam nach wenigen Stunden und später auch bereits nach wenigen Minuten zu einem automatischen Reboot oder gar kompletten Stillstand (nur Aus/Ein Schalten war noch möglich).
In keinem mir bekannten Log gibt es irgendeine Fehlermeldung dazu, weder in den Linux logs noch in dem ioBroker Log.
Danach habe ich ein Update auf alle möglichen Komponenten gemacht, sodaß ich jetzt folgende Versionen im Einsatz habe:
-
Raspian - Linux version 4.0.8-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #804 SMP PREEMPT Tue Jul 14 13:03:16 BST 2015
-
node - v0.12.6
-
mosquitto version 1.4.2 (build date Mon, 18 May 2015 15:25:19 +0100)
-
ioBroker.js-controller 0.7.5 und alles auf –production Versionen
Auf der Suche nach einer eventuellen Ursache habe ich dann auch den RPi Monitor öfters in den entsprechenden Situation aufgerufen und dabei viel mir stetig die fallende Kurve des freien Speichers auf.
Dazu habe ich dann mit
topund der Sortierung nach Speicherverbrauch (Shift + M) den freien Speicher beobachtet.
Die folgenden Daten sind ohne jegliche User Aktvitäten im Frontend entstanden:
root@raspberrypi:/opt/iobroker# iobroker stop Stopping ioBroker controller daemon... ioBroker controller daemon stopped. root@raspberrypi:/opt/iobroker# top top - 21:51:49 up 2:21, 2 users, load average: 0,04, 0,11, 0,13 Tasks: 89 total, 1 running, 88 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,2 us, 0,1 sy, 0,0 ni, 99,7 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st KiB Mem: 948256 total, 143680 used, 804576 free, 39580 buffers KiB Swap: 524284 total, 0 used, 524284 free, 64112 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2202 root 39 19 19152 8664 3020 S 0,0 0,9 0:34.16 rpimonitord 2201 pi 39 19 19260 8376 2704 S 0,0 0,9 0:00.02 rpimonitord 2194 root 39 19 19152 8112 2468 S 0,0 0,9 0:00.03 rpimonitord 2282 pi 20 0 6860 4576 2752 S 0,0 0,5 0:00.62 bash ... root@raspberrypi:/opt/iobroker# iobroker restart ioBroker controller daemon is not running Starting ioBroker controller daemon... ioBroker controller daemon started. PID: 10080 root@raspberrypi:/opt/iobroker# top top - 21:52:31 up 2:22, 2 users, load average: 0,31, 0,16, 0,15 Tasks: 93 total, 3 running, 90 sleeping, 0 stopped, 0 zombie %Cpu(s): 53,1 us, 2,1 sy, 0,0 ni, 44,8 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st KiB Mem: 948256 total, 226256 used, 722000 free, 39612 buffers KiB Swap: 524284 total, 0 used, 524284 free, 64120 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10093 root 20 0 97384 48m 10m R 75,8 5,2 0:06.96 io.admin.0 10080 root 20 0 91412 35m 11m S 54,1 3,9 0:04.89 io.js-controlle 10108 root 20 0 85896 26m 10m R 88,7 2,9 0:03.26 node 2202 root 39 19 19152 8664 3020 S 0,0 0,9 0:34.32 rpimonitord 2201 pi 39 19 19260 8376 2704 S 0,0 0,9 0:00.02 rpimonitord 2194 root 39 19 19152 8112 2468 S 0,0 0,9 0:00.03 rpimonitord 2282 pi 20 0 6860 4576 2752 S 0,0 0,5 0:00.62 bash ... root@raspberrypi:/opt/iobroker# top top - 21:53:18 up 2:23, 2 users, load average: 0,38, 0,22, 0,17 Tasks: 96 total, 1 running, 95 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,5 us, 0,2 sy, 0,0 ni, 98,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 948256 total, 304724 used, 643532 free, 39660 buffers KiB Swap: 524284 total, 0 used, 524284 free, 64124 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10080 root 20 0 99,6m 52m 11m S 2,3 5,7 0:09.76 io.js-controlle 10093 root 20 0 99,5m 52m 10m S 3,0 5,7 0:10.25 io.admin.0 10125 root 20 0 90896 34m 11m S 0,0 3,8 0:06.39 io.hm-rega.0 10136 root 20 0 96064 34m 10m S 0,0 3,7 0:06.51 io.web.0 10108 root 20 0 94048 33m 11m S 0,3 3,6 0:06.04 io.hm-rpc.0 2202 root 39 19 19152 8664 3020 S 0,0 0,9 0:34.46 rpimonitord 2201 pi 39 19 19260 8376 2704 S 0,0 0,9 0:00.02 rpimonitord 2194 root 39 19 19152 8112 2468 S 0,0 0,9 0:00.03 rpimonitord 2282 pi 20 0 6860 4576 2752 S 0,0 0,5 0:00.62 bash ... root@raspberrypi:/opt/iobroker# top top - 21:57:59 up 2:28, 2 users, load average: 0,04, 0,13, 0,15 Tasks: 95 total, 1 running, 94 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,1 us, 0,2 sy, 0,0 ni, 99,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 948256 total, 311364 used, 636892 free, 39856 buffers KiB Swap: 524284 total, 0 used, 524284 free, 64124 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10080 root 20 0 99,8m 54m 11m S 0,0 5,9 0:14.43 io.js-controlle 10093 root 20 0 99,3m 52m 10m S 0,0 5,7 0:14.75 io.admin.0 10125 root 20 0 91920 37m 11m S 0,0 4,1 0:07.78 io.hm-rega.0 10136 root 20 0 96064 35m 10m S 0,0 3,8 0:07.27 io.web.0 10108 root 20 0 95320 34m 11m S 0,3 3,7 0:08.02 io.hm-rpc.0 2202 root 39 19 19152 8664 3020 S 0,0 0,9 0:35.51 rpimonitord 2201 pi 39 19 19260 8376 2704 S 0,0 0,9 0:00.02 rpimonitord 2194 root 39 19 19152 8112 2468 S 0,0 0,9 0:00.03 rpimonitord 2282 pi 20 0 6860 4576 2752 S 0,0 0,5 0:00.62 bash ... root@raspberrypi:/opt/iobroker# top top - 22:02:12 up 2:32, 2 users, load average: 0,06, 0,15, 0,15 Tasks: 95 total, 1 running, 94 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,1 us, 0,3 sy, 0,0 ni, 98,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 948256 total, 318464 used, 629792 free, 40056 buffers KiB Swap: 524284 total, 0 used, 524284 free, 64132 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10080 root 20 0 100m 55m 11m S 2,0 6,0 0:18.24 io.js-controlle 10093 root 20 0 100m 52m 10m S 2,0 5,7 0:18.29 io.admin.0 10125 root 20 0 92944 41m 11m S 0,3 4,5 0:09.18 io.hm-rega.0 10108 root 20 0 97368 36m 11m S 0,0 3,9 0:10.04 io.hm-rpc.0 10136 root 20 0 96064 36m 10m S 0,3 3,9 0:07.73 io.web.0 2202 root 39 19 19152 8664 3020 S 0,0 0,9 0:36.44 rpimonitord 2201 pi 39 19 19260 8376 2704 S 0,0 0,9 0:00.02 rpimonitord 2194 root 39 19 19152 8112 2468 S 0,0 0,9 0:00.03 rpimonitord 2282 pi 20 0 6860 4576 2752 S 0,0 0,5 0:00.62 bash ... root@raspberrypi:/opt/iobroker# top top - 22:06:11 up 2:36, 2 users, load average: 0,26, 0,22, 0,17 Tasks: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,3 us, 0,5 sy, 0,1 ni, 99,0 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st KiB Mem: 948256 total, 321764 used, 626492 free, 40244 buffers KiB Swap: 524284 total, 0 used, 524284 free, 64136 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10080 root 20 0 101m 55m 11m S 1,0 6,0 0:21.67 io.js-controlle 10093 root 20 0 100m 53m 10m S 1,3 5,8 0:21.62 io.admin.0 10125 root 20 0 92944 41m 11m S 0,3 4,4 0:10.24 io.hm-rega.0 10108 root 20 0 98392 37m 11m S 0,0 4,0 0:11.36 io.hm-rpc.0 10136 root 20 0 96064 36m 10m S 0,0 4,0 0:08.20 io.web.0 2202 root 39 19 19152 8664 3020 D 0,3 0,9 0:37.38 rpimonitord 2201 pi 39 19 19260 8376 2704 S 0,0 0,9 0:00.02 rpimonitord 2194 root 39 19 19152 8112 2468 S 0,0 0,9 0:00.03 rpimonitord 2282 pi 20 0 6860 4576 2752 S 0,0 0,5 0:00.62 bash ... root@raspberrypi:/opt/iobroker# top top - 22:15:28 up 2:45, 2 users, load average: 0,00, 0,04, 0,11 Tasks: 96 total, 1 running, 95 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,8 us, 0,9 sy, 0,2 ni, 97,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 948256 total, 336028 used, 612228 free, 40644 buffers KiB Swap: 524284 total, 0 used, 524284 free, 64144 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10080 root 20 0 102m 56m 11m S 4,0 6,1 0:29.62 io.js-controlle 10093 root 20 0 100m 54m 10m S 2,3 5,8 0:29.13 io.admin.0 10125 root 20 0 93820 45m 11m S 0,0 4,9 0:12.83 io.hm-rega.0 10108 root 20 0 99,1m 43m 11m S 0,7 4,7 0:14.40 io.hm-rpc.0 10136 root 20 0 96064 38m 10m S 0,3 4,1 0:08.95 io.web.0 2202 root 39 19 19152 8664 3020 S 1,3 0,9 0:39.65 rpimonitord 2201 pi 39 19 19260 8376 2704 S 0,0 0,9 0:00.02 rpimonitord 2194 root 39 19 19152 8112 2468 S 0,0 0,9 0:00.03 rpimonitord 2282 pi 20 0 6860 4576 2752 S 0,0 0,5 0:00.62 bash ... root@raspberrypi:/opt/iobroker# top top - 22:26:00 up 2:56, 2 users, load average: 0,00, 0,06, 0,10 Tasks: 95 total, 1 running, 94 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,4 us, 0,4 sy, 0,0 ni, 99,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 948256 total, 345784 used, 602472 free, 41132 buffers KiB Swap: 524284 total, 0 used, 524284 free, 64168 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10080 root 20 0 104m 57m 11m S 0,0 6,2 0:38.24 io.js-controlle 10093 root 20 0 105m 55m 10m S 0,0 6,0 0:38.13 io.admin.0 10108 root 20 0 100m 48m 11m S 0,0 5,2 0:17.41 io.hm-rpc.0 10125 root 20 0 94636 46m 11m S 0,0 5,0 0:15.98 io.hm-rega.0 10136 root 20 0 96064 39m 10m S 0,0 4,3 0:09.95 io.web.0 2202 root 39 19 19152 8664 3020 S 0,0 0,9 0:42.28 rpimonitord 2201 pi 39 19 19260 8376 2704 S 0,0 0,9 0:00.02 rpimonitord 2194 root 39 19 19152 8112 2468 S 0,0 0,9 0:00.03 rpimonitord 2282 pi 20 0 6860 4576 2752 S 0,0 0,5 0:00.62 bash ...Nachdem sich nach einem Neustart durch
iobroker restartdas System "eingeschwungen" hat, hat sich der freier Speicher wie folgt verändert:
-
22:02:12 629792 free
-
22:06:11 626492 free
-
22:15:28 612228 free
-
22:26:00 602472 free
Dies geht bis zu einem Zeitpunkt weiter, an welchen das System "stirbt".
Was kann ich tun?
Gruß
Frank
-
-
Auch eine komplett neue Installation ohne jeglichen Adapter oder Zusatz verbraucht mit der Zeit Speicher.
root@raspberrypi:/opt/iobroker# top top - 21:37:11 up 13 min, 2 users, load average: 0,37, 1,78, 1,45 Tasks: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,2 us, 0,7 sy, 0,3 ni, 98,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 948256 total, 373316 used, 574940 free, 34796 buffers KiB Swap: 524284 total, 0 used, 524284 free, 173664 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3223 root 20 0 133m 79m 11m S 0,0 8,6 0:25.55 io.js-controlle 3236 root 20 0 98100 49m 11m S 0,0 5,3 0:11.16 io.admin.0 2175 root 39 19 19152 8612 2968 S 1,3 0,9 0:02.95 rpimonitord ... root@raspberrypi:/opt/iobroker# top top - 21:38:59 up 14 min, 2 users, load average: 0,20, 1,30, 1,31 Tasks: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,8 us, 0,2 sy, 0,0 ni, 98,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 948256 total, 373724 used, 574532 free, 34888 buffers KiB Swap: 524284 total, 0 used, 524284 free, 173664 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3223 root 20 0 133m 79m 11m S 1,7 8,6 0:26.17 io.js-controlle 3236 root 20 0 98360 49m 11m S 2,0 5,4 0:12.03 io.admin.0 2175 root 39 19 19152 8612 2968 S 0,0 0,9 0:03.39 rpimonitord ... root@raspberrypi:/opt/iobroker# top top - 21:51:18 up 27 min, 2 users, load average: 0,00, 0,15, 0,64 Tasks: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,8 us, 0,0 sy, 0,0 ni, 99,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 948256 total, 374556 used, 573700 free, 35400 buffers KiB Swap: 524284 total, 0 used, 524284 free, 173664 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3223 root 20 0 133m 79m 11m S 0,0 8,6 0:29.55 io.js-controlle 3236 root 20 0 99972 50m 11m S 0,8 5,5 0:16.86 io.admin.0 2175 root 39 19 19152 8612 2968 S 0,0 0,9 0:06.60 rpimonitord ... root@raspberrypi:/opt/iobroker# -
Auf der weiteren Suche nach einem Fehler habe ich nun auch noch per rpi-update folgende Version im Einsatz
Raspbian Linux raspberrypi 4.1.4-v7+ #808 SMP PREEMPT Thu Aug 6 16:59:39 BST 2015 armv7lAber auch das hat keine Verbesserung gebracht.
Danach habe ich noch den Hardware Watchdog ativiert, damit ich das System nicht immer manuell aus/ein-schalten muss. Denn es kommt ja zu einem Stillstand. Dabei habe ich nun folgende Auffälligkeit:
Aug 6 23:17:11 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 00:17:10 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 07:17:10 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 07:17:09 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 08:17:11 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 09:17:09 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00Das Memory Leak ist nach wie vor da, aber der Stillstand des Systems passiert anscheinend nicht durch zu wenig Memory, sondern zu einer bestimmen Zeit. :?: :?: :?:
-
Auf der weiteren Suche nach einem Fehler habe ich nun auch noch per rpi-update folgende Version im Einsatz
Raspbian Linux raspberrypi 4.1.4-v7+ #808 SMP PREEMPT Thu Aug 6 16:59:39 BST 2015 armv7lAber auch das hat keine Verbesserung gebracht.
Danach habe ich noch den Hardware Watchdog ativiert, damit ich das System nicht immer manuell aus/ein-schalten muss. Denn es kommt ja zu einem Stillstand. Dabei habe ich nun folgende Auffälligkeit:
Aug 6 23:17:11 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 00:17:10 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 07:17:10 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 07:17:09 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 08:17:11 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00 Aug 7 09:17:09 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00Das Memory Leak ist nach wie vor da, aber der Stillstand des Systems passiert anscheinend nicht durch zu wenig Memory, sondern zu einer bestimmen Zeit. :?: :?: :?: `
Bist du sicher, dass ohne ioBroker dein System stabil läuft?Dann werde ich versuchen alle Adapter ausschalten und ein nach dem anderem aktivieren und Stabilität beobachten.
-
Bist du sicher, dass ohne ioBroker dein System stabil läuft?
Dann werde ich versuchen alle Adapter ausschalten und ein nach dem anderem aktivieren und Stabilität beobachten. `
Eigentlich ja, aber ich werde trotzdem Deinen Vorschlag versuchen.
Danke.
-
Hallo,
ich habe jetzt auch seit ca. einer Woche das Problem, dass die node.js Prozesse immer weiter anwachsen bis nichts mehr geht. Da ich einige Skripte unter node-red laufen habe ist meistens nach ca. 8 Stunden Schluss.
Meine Vermutung ist, dass das Problem mit den Wechsel auf node.js 0.12.7 angefangen hat und seitdem die Garbage Collection nicht mehr korrekt ausgeführt wird. Alle Prozesse unter node.js wachsen langsam aber stetig immer weiter an.
Ich habe jetzt mal in die Startzeile von node-red in der main.js den Parameter –max-old-space-size=128 aufgenommen, wie es unter http://nodered.org/docs/hardware/raspberrypi.html beschrieben ist. Mal sehen, ob dies was bringt.
Gruß
Markus
Pi2 - Raspian mit Upgrade auf Debian 8 (Jessie)
node.js 0.12.7
-
Bist du sicher, dass ohne ioBroker dein System stabil läuft?
Dann werde ich versuchen alle Adapter ausschalten und ein nach dem anderem aktivieren und Stabilität beobachten. `
Habe Deinen Vorschlag umgesetzt. Zuerst habe ich das System komplett ohne ioBroker laufen lassen. Und leider (oder auch gut so) war das System instabail. Diesen Fehler haben laut Google Suche auch viele andere auch. Wer selber suchen und lesen möchte hier die Suche
https://www.google.de/#q=raspberry+%2Fetc%2Fcron.hourly+crashLeider sind die Lösungen sehr sehr sehr unterschiedlich.
In meinem Falle war es das Netzteil. Ja, richtig gelesen, das Netzteil. Ich habe schon seit langer Zeit so 1A Netzteil aus China im Einsatz. Nachdem ich dieses durch ein Netzteil mit 2A von Apple ( ich hatte nichts anderes gerade zur Hand) läuft das System stabil… zumindestens gibt es keine Stillstände mehr um hh:17:10.
An dem Memory Leak hat sich allerdings nichts geändert. Nach 24 Stunden Laufzeit sieht es wie folgt aus:
top - 15:04:32 up 2 days, 1:24, 2 users, load average: 0,93, 0,44, 0,29 Tasks: 97 total, 1 running, 96 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,4 us, 0,0 sy, 0,0 ni, 73,1 id, 24,8 wa, 0,0 hi, 0,7 si, 0,0 st KiB Mem: 948128 total, 934644 used, 13484 free, 36232 buffers KiB Swap: 524284 total, 480 used, 523804 free, 78880 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2138 root 20 0 204m 146m 5556 S 0,0 15,8 136:26.61 io.js-controlle 7561 root 20 0 196m 140m 5332 S 0,0 15,2 19:42.59 node-red 2384 root 20 0 144m 89m 5188 S 0,0 9,6 9:53.54 io.hm-rega.0 2180 root 20 0 136m 82m 6192 S 0,0 8,9 54:57.60 io.admin.0 2349 root 20 0 127m 73m 5384 S 0,0 7,9 12:10.85 io.hm-rpc.0 9965 root 20 0 121m 66m 5436 S 0,0 7,2 18:50.43 io.javascript.0 2195 root 20 0 117m 62m 5364 S 0,0 6,7 63:00.88 io.history.0 2404 root 20 0 105m 51m 5548 S 0,0 5,5 6:54.32 io.mqtt.0 2292 root 20 0 100m 45m 5228 S 0,0 4,9 3:14.04 io.web.0 7543 root 20 0 95532 38m 5336 S 0,0 4,1 1:13.44 io.node-red.0 2207 pi 39 19 19532 8768 2784 S 0,0 0,9 0:00.26 rpimonitordDaher ändere ich den Thread Titel ein wenig ab.
Gruß
Frank
-
Ganz normal mit der Anleitung aus der Doku von node.js für Debian.
https://github.com/joyent/node/wiki/Ins … ge-manager
Gesendet von meinem SM-G900F mit Tapatalk
-
Ganz normal mit der Anleitung aus der Doku von node.js für Debian.
Entsprechend Deines Links http://nodered.org/docs/hardware/raspberrypi.html habe ich die Installation für den Raspberry Pi 2 durchgeführt. Somit habe ich nun auch node.js 0.12.7 im Einsatz.
Aber das Memory Leak ist geblieben. Nach einer gewissen Laufzeit sieht es dann wieder so aus:
` > top - 21:05:42 up 3 days, 7:25, 2 users, load average: 0,18, 0,25, 0,25
Tasks: 98 total, 1 running, 97 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1,8 us, 0,7 sy, 0,3 ni, 97,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 948128 total, 935904 used, 12224 free, 57724 buffers
KiB Swap: 524284 total, 1428 used, 522856 free, 68220 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5876 root 20 0 216m 162m 7008 S 3,3 17,5 95:09.24 io.js-controlle
29820 root 20 0 157m 108m 10m S 1,0 11,7 24:47.01 node-red
5889 root 20 0 135m 82m 6424 S 1,0 9,0 38:19.70 io.admin.0
6040 root 20 0 133m 80m 6504 S 0,7 8,7 33:45.99 io.javascript.0
5958 root 20 0 131m 78m 6488 S 0,3 8,4 6:06.92 io.hm-rega.0
5930 root 20 0 128m 75m 6328 S 0,0 8,1 7:06.69 io.hm-rpc.0
5903 root 20 0 119m 66m 6344 S 1,7 7,2 40:06.19 io.history.0
5968 root 20 0 107m 53m 6824 S 0,3 5,8 5:06.44 io.mqtt.0
29770 root 20 0 96440 44m 10m S 0,0 4,8 1:27.15 io.node-red.0
5913 root 20 0 98,2m 43m 6320 S 0,0 4,7 1:52.84 io.web.0
2207 pi 39 19 19532 8428 2444 S 0,0 0,9 0:00.52 rpimonitord
… `
-
Die Zahlen sagen leider nicht viel aus. node.js basiert auf Google V und dieses gibt wie die meisten Egmascript Engines den über Variablen und Objekte allokierten Speicher nicht automatisch nach den Setzen der Variablen auf NULL frei sondern erst durch den Lauf einer sogenannten Garbage Collection.
Die springt an, wenn ein Maximalwert erreicht wird oder wenn die Anwendung diese manuell startet. Zumindest nodered startet die Garbage Collection nicht selbst. Aus diesem Grund ist hier der Maximalwert sehr wichtig.
Bei node.js 0.12.x liegt der Default-Wert bei 512MB. Dieser Wert gilt pro Instanz. Jeder Adapter und der Controler starten eigenen Prozess und müssten somit eine eigene node.js Instanz sein.
Da der Pi2 nur 1 GB Hauptspeicher hat, wird es da schnell eng. Deswegen sollte der maximal belegbare Speicher über den Parameter reduziert werden. Dies sollte für alle node.js Prozesse erfolgen. Ich hab das jetzt erstmal für nodered gemacht, was den Adapter auf ca. 11% begrenzt.
Generell ist die Garbage Collection von V8 problematisch. Diese arbeitet nach dem Stop-the-World Modell. D.h. solange der Speicher aufgeräumt wird, werden alle threads des Prozesses gestoppt. Auch kann dies auf dem pi schonmal eine zweistellige Anzahl von Sekunden dauern. Wenn dies erst an der Systemgrenze erfolgt, bekommen in der Zeit andere Prozesse keinen neuen Speicher und die werfen dann eine Exeption oder einen Core.
Wäre mal interessant zu erfahren, wie die eigenen Komponenten von iobroker mit der Garbage Collection umgehen.
https://strongloop.com/strongblog/node- … ollection/
Gesendet von meinem GT-N8000 mit Tapatalk
-
Besser konnte ich auch nicht erklären.
Es werden momentan keine Speicher-Limitierungen benutzt.
Sollte man vielleicht. `
Dann setze ich den Thread mal auf [gelöst].
In meinem Fall wird der Speicher langsam "voll", aber das System läuft dann trotzdem ohne Probleme weiter.
Gruss
Frank
-
Ich wollte mich mal hier einklinken. Habe jetzt auch auf 0.12.7 geupdated und exakt das gleiche Problem.
Vorher hatte ich bei laufendem ioBroker noch immer ca. 200 MB Ram frei, jetzt läuft der Speicher recht schnell voll, dabei habe ich nichtmal eine node-red Instanz laufen. Das System läuft dann erstmal weiter stabil, wenn auch spürbar langsamer. Es kommt aber bei Update/Installation von Adapter vor, dass das ganze system so langsam wird, dass offene Sockets in ioBroker timouts bekommen und adapter abstürzen.
Support us
763
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge