Node-Red High CPU causes status "Initializing" and disables the Restart button

When I push a Node-Red flow pretty hard, I will get this in groov Manage:

I’ve noticed that the Status will change from “Running” to “Initializing” when the CPU gets to be around 45%.

I would like to be able to use the Disable or Restart buttons on the Node-Red service when this happens, but the buttons get disabled whenever the status is “Initializing”.

What hardware and what firmware version is this on?
Reason I ask is there is a ticket in to tweak the responsiveness of this page and I wanted to check where you are seeing it vs the ticket.

Thanks.

RIO 3.3.1-b.112

There may be some interaction with the UDP streaming as well. When the streaming rate is set too fast for the RIO to handle, turning off the streaming (Writing 0 to 0xF03FFFD0) doesn’t stop it - the MMP server continues to stream data. I have to write a longer interval first (0xF03FFFD4) and then turn off the streaming. I’ve noticed that the interval must be even longer to prevent this from happening when Node-Red is heavily loaded.

So when I “overload” the RIO to the point that Node-Red Deploy fails, my procedure now is to increase the streaming interval (through the Generic MMP tool in manage), then disable streaming, then I can fix things in Node-Red.

Hey @philip that is somewhat different (mostly the streaming bit) from the ticket about the Node-RED status page.
I ran your post past engineering and if you could pretty much cut/paste it in an email to support and start that process the team here would appreciate it.

Thanks.

I’ll need to create a sample flow for them to test with. It may be a while until I can get to that.

No, I don’t think that’s required.
Just the streaming addresses you have in the last post is enough.
We don’t need anything to stress Node-RED per-say. Tell em to see me if they need more!!

After experimenting with this, the OptoMMP UDP streaming works fine.

The issue is in my Node-Red flow that just takes too long to process the data that comes in and it seems the “UDP in” node (or Node-Red itself) is able to buffer quite a bit of data and continues to process it after the stream has stopped. Sometimes this takes a while to get all flushed out.

The Status does change to Initializing whenever this happens - it seems that the Status changes based on the responsiveness of Node-Red.

Ah, Ok, that sort of changes things a bit then.
I was thinking there was a clear bug with the MMP scanner and that was my focus.
The Node-RED status page does check the ‘availability’ of the Node-RED server once a second, so if it times out, ie Node-RED is not able to serve up a connection then the page will show “Initializing”. I think one of the changes we are looking at for that page is to keep track of once its initialized, but then does not respond, then it should show ‘Busy’… Anyway, bit of a moot point in your case as it seems to simply be a case of doing too much nodejs goodness on a single core CPU.

And yes, I have seen your exact description even on my 8core 3.2 GHz 32 gig of RAM windows box at home running my main Node-RED project. Some of the aircraft messages can pull back over 30,000 messages in a burst and if things are not done right, they can get pretty badly buffered and things go a bit sideways till its all cleared out. I put a delay node in with .01 second delays to just help it breath. Your UDP stream will struggle with any sort of delay like that, so its tough to suggest much more not knowing why your application needs such high speed.

The higher speed is for a stupid reason - just to detect a button push that is on a channel higher than 0 or 1 where there is no latching feature. Nothing else requires a high speed and there are pulse inputs on the first two channels so they are not available.

Have you tested moving the scanning of those extra inputs to Python? (Rather than UDP in Node-RED).

No, I’m sure there are lot’s of other ways that can be explored - there are currently several RIOs that are using this logic with plans for many more. Something that is easy to deploy and maintain is a concern so I am avoided setting up shell.

I haven’t explored all my avenues with Node-Red yet either. There is also the end user training option- “hold button for 1 second - it’s a feature!”

The new fast read method :sunglasses:

Who needs REST? I guess I need to handle the PUC with this method though.

2 Likes