CRASHES NODE-RED Multiple dashboards oppened in any brownser

General
1

Hi node-guys i am with some trouble and accessing my dashboard takes the memory out of control and crashes node-red service. I think most of us use dashboard for something and i would like to know if you have some trouble we may achieve some solution. Since now I appreciate your opninons so much. :slight_smile:

What are the steps to reproduce?

Multiple node-red dashboard opened in different browsers in web during a period of time.

What happens?

Crash the node-red application service!

What do you expect to happen?

Not crash the application of Node-red service

Please tell us about your environment:

  • Node-RED version: v0.17.5

  • node.js version: v8.9.4

  • npm version: 5.6.0

  • Platform/OS: Ubuntu 16.04.09

  • Browser: Any brownser in notebooks, tablets, tvs

###Node-RED log file with error:

<--- Last few GCs --->

[18497:0x30b4aa0]  8308665 ms: Mark-sweep 130.7 (156.0) -> 130.7 (146.0) MB, 175.0 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 175 ms) last resort GC in old space requested
[18497:0x30b4aa0]  8308817 ms: Mark-sweep 130.7 (146.0) -> 130.7 (146.0) MB, 152.0 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x10235ca5ee1 <JSObject>
    2: sendPacket [/home/smartcampus/.node-red/node_modules/engine.io/lib/socket.js:380] [bytecode=0x3bec63321789 offset=37](this=0xc22273c2861 <Socket map = 0x244308ce53b9>,type=0x2f3e45697231 <String[4]: open>,data=0x7e89751ccc1 <String[96]: {"sid":"4SMSHo3Chj7jlU28AAJD","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":60000}>,options=0x7e89751cce9 <Object map = 0x3e9e132823b9>,callb...
2

You realize you are trunning a vey oold version of Node-RED? tThe current release is v0.19.5. I don't know if that will make a difference, but my suggestion would be to backup your stuff and upgrade and test again.

3

Hi @zenofmud! Thanks for reply!

The dash is public so before any tries I would really like to know whats is exatly happen. I suspect the update may not resolv the problem or tell me what it is.

I appreciate your comment and take into consideration.

4

If you can't experiment with the production system then set up another one with the same versions of everything and try and replicate the issue.

How many simultaneous connections are you running?

5

Hi Rogerio,
I have a had numerous times a similar problem with a single dashboard, by pushing too many data (audio and video) to it. Seems the websocket cannot handle all the data, so I have to reboot my entire Raspberry. One would indeed expect that the flow should keep running, and only the dashboard would be kicked out ...

So perhaps you might have a similar problem. I thought (??) that a websocket connection will be kept open for every connected dashboard, soand again lots of system resources are consumed...

I didn't have time yet to investigate further :frowning_face: But perhaps you can experiment with appmetrics, and hopefully you get an indication where in NodeJs things are going wrong. And then we can discuss your results here... I think @TotallyInformation has written some explanation about the appmetrics some time ago, but I cannot find it anymore.
Bart

6

Hello @Colin!

Thanks for the advice! Really i dont have how to replicate because it is openned in DNS. It is complicated open in internet just on intranet and maybe.

I have openned for about 10 dashes in ten simultâneos guides in firefox and chrome. So, after sometime the application crashed.

I have for about 38 widgets

There are a lot of nodes and they are working with mqtt. each node with 8 minutes with receiving data. da

7

We really can't see what is causing that because there are too many variables. You would need to record how many connections are live for a start. If you have hundreds or thousands, that might be causing issues. We would also need to understand how much data is being pushed each way through the sockets. Also, we would need to understand what the flow is - is there a node that isn't working correctly?

Upgrading won't tell you what the issue is, you are right. However, with the complexity of Node-RED, Dashboard, Node.JS, ExpressJS, etc all being involved, tracking down this kind of error is a horrible job at best.

I created a quick write-up of how to use Visual Studio Code debugging with Node-RED. Others have done similar using Chrome debugging tools I think. However, this doesn't help debug a live system, only one that you can run manually and if it is the number of connections that is contributing to the issue, then you may never see the problem.

Given the GC triggers, it is likely that this is a memory leak somewhere. You could monitor that by monitoring the resource use on the server.

Realistically, you are faced with walking through each part of your flow and trying to simplify and optimise it. Then try to simplify your Dashboard. Then you may have to try to apply limits to the number of connections allowed or to upgrade your server hardware.

Alternatively, it might be a lot quicker and easier to rewrite your dashboard in something lighter-weight. Dashboard is great for getting started as it does so much heavy lifting for you. However, you pay for that by the amount of both front- and back-end resources it can use up.