NEWS
[gelöst] Speicherleck? Memory Leak?
-
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
666
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge