Node.js - Programm bringt RPi 2 zum rebooten?

  • Hallo,
    ich habe nun seit tagen folgendes Problem: Mein in Node.js geschriebenes Programm ist ständig wegen zu wenig RAM abgestürzt - dieses Problem ist mittlerweile behoben (Zuletzt geänderten Code einfach rückgängig), nun hab ich aber das Problem dass wenn ich auf das Webinterface zum ersten mal gehe, alles funktioniert und ich alles machen kann, warte ich jedoch ca 5-10 min und gehe wieder drauf, lädt sich die Seite zu tode und der RPi rebootet einfach.


    Woran kann das liegen? Derselbe Code hat zuvor einwandfrei Funktioniert.
    Hab auch schon alles versucht, verschiedene Distros ausprobiert, verschiedene Node.js versionen, verschiedene npm Versionen etc., jedoch hat nichts davon geholfen.


    Hoffe jemand kann mir bei dem Problem helfen. :(

  • Moin,
    schon mal in den Logdateien nachgesehen?? /var/log/syslog oder mit dem Befehl "journalctl"


    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"

    Vielleicht trifft man sich in der RPi-Plauderecke.

  • Pures Node.js out of the box? Oder irgendwelche native Erweiterungen (die durchaus auch das Problem sein könnten? Ohne Code zu sehen ohnehin schwer zu beantworten.

  • Versuch mal einen neuen Pi, ich habe

    • Node-RED mit einigen interfaces zu MQTT und einigen REST API's
    • motion (verbrauch die meiste CPU da es als Bewegungsmelder läuft und Node-RED verschickt Bilder und mail wenn sich was tut)
    • haproxy
    • node.js web server mit express (schau mal auf http://cwbuecheler.com/web/tut…/2013/node-express-mongo/)
    • node.js web sockets mit express
    • MongoDB
    • RPI-Monitor (versuch den mal, da kannste super die Temperatur, Memory und CPU-Belastung der letzten Stunden sehen) mit Shellinabox
    • Xtightvnc
    • lightttp mit php5 (wird bald rausfliegen...)
    • Samba server


    htop meldet

    • 7,5% memory für node-Red
    • 4.4% für mongod
    • 3,5% für den node.js express web server
    • 2,5% + 1,9% für den graphischen desktop lxxxx (wird bald rausfliegen)
    • 2% smbd (Samba)


    Sonst also insgesamt weniger als 50% und ich hatte noch nie zu wenig Speicher.


    Die CPU-Belastung im Durchschnitt unter 5% (RPI 3) und die Temperatur mit einer Alu-Kühlrippe und einem aufgesetzten Space Hat unter 50°.


    p.s. verwende node.js 4.2

    Frank


    Nach 35 Jahren im IT business hab ich mit Raspi mal selbst zum Programmieren begonnen...
    Habe auch einen 3D-Drucker, eine CNC-Fräse und etwas Elektronik-Bastelei als Hobby


  • Moin,
    schon mal in den Logdateien nachgesehen?? /var/log/syslog oder mit dem Befehl "journalctl"


    Gruss Bernd


    Code
    Apr 17 00:22:15 raspberrypi kernel: [  360.861653] Out of memory: Kill process 937 (node) score 824 or sacrifice child
    Apr 17 00:22:15 raspberrypi kernel: [  360.861667] Killed process 937 (node) total-vm:956568kB, anon-rss:843236kB, file-rss:1308kB
    Apr 17 00:22:15 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Apr 17 00:22:45 2016 [try http://www.rsyslog.com/e/2007 ]




    Pures Node.js out of the box? Oder irgendwelche native Erweiterungen (die durchaus auch das Problem sein könnten? Ohne Code zu sehen ohnehin schwer zu beantworten.


    Ja, ist pures Node.js out of the Box mit ein paar Modulen, die aber nicht das Problem sein können, da wie gesagt vorher alles mit denselben Modulen funktioniert hat.


    Code: http://pastebin.com/EVLpHYaS


    Könnten die teilweise schlecht gelösten Sachen das Problem sein?



    Out of Memory Fehler ist wohl doch nicht behoben, was könnte das denn sein wenn alles vorher glatt lief?
    Sorry für die verspätete Rückmeldung, hatte viel um die Ohren


  • Möglicherweise hast du ein Memory Leak in deiner node.js Anwendung.
    Es gibt Hilfsprogramme mit denen man solche Leaks finden kann, beispielsweise heapdump (npm install heapdump).
    Weitere Infos gibt's zum Beispiel hier: https://strongloop.com/strongb…ek-memory-leak-diagnosis/


    Perfekt, Danke!
    Fehler war ein setTimeout was falsch gesetzt wurde, wodurch die Funktion in immer kürzeren Abständen ausgeführt wurde, bis es letztlich zu viel wurde.