Node-RED

[Solved] Raspberry PI 3B with Node Red causes high CPU load when Chromium start locally

#1

hi there, I am gaining my first experiences with Node Red with a deployment on a Raspberry Pi 3B.
My test flows work fine when accessing the dashboard / gui from other stations (e.g. Laptop with Chrome browser).

For (emergency) remote access however, I also have VNC running on that Raspberry Pi. This is to access and control not only the "local" Node Red installation but also my home automation controller located in the same network.

When I access the UI for the homematic (RaspberryMatic) device, all seems ok. After a short CPU peak to about 10%, it returns to "doing nothing" ~ 2-3% load.

However, when I access the local Node Red Dashboard / UI, the cpu load climbs very quickly to a steady 60+ % load and stays at that level for as long as I was monitoring it. On that pi I am currently using the default installed Chromium browser. As mentioned before, when accessing that pi from a remote networked computer, the CPU load is basically NOT impacted.

I now also tried accessing the Node-Red instance on the homematic raspberry pi (RaspberryMatic with RedMatic to be precise) and similar, the CPU load goes to about 33% and stays there. So, not as bad as visualising the local instance but still considerable load!

So, that leads me to my question - how can this be fixed?

Will a different browser work "better"? Is there an issue with showing the dashboard / UI on a local node? Can the "load" be influenced by controlling refresh rates or similar (if so how / where)?

THANKS!

#2

As you've found, running Chromium on a Pi uses a lot of resources and that's just the nature of the app.

But, 60% isn't really a problem - there is still 40% left to go so its generally not an issue.

#3

Thank you cymplecy,

Personally, I don't feel comfortable with a base load of 60%.

For testing I installed the classicer Midori, and the CPU load is now closer to 30%.

I wonder if anyone else has another browser to recommend?

THANKS!

#4

have you read the RaspberryPI "getting started" page in the docs?

#5

Sorry, I have to admit I haven't! As I ended up with Node Red on the Homematic RaspberryMatic, the stand-alone installation was an "afterthought" (and was actually easier then the Homematic RedMatic deployment).
I will probably have to do so!
I presume there is a reference to browser issue or you wouldn't have brought it up!
Thanks for the suggestion!

#6

Actually, I just had a look and what I found, I have read as I had issues with the auto start in my first deployment on a Raspberry Pi that was simulated (!) on VMWare. Got it to work but it took a bit longer then the installation now on my physical device!
https://nodered.org/docs/getting-started/raspberrypi

When I look back it states:
We recommend Chromium or Firefox-ESR on the Pi and not Epiphany

So, my issue is with Chromium for the UI end (I am not planning to do development in the Rpi browser).

And as indicated, my initial experience with Midori is about half the CPU load as with Chromium.

Is it worth my while to try Firefox as well?

THANKS

#7

Before switching browsers, I would take a look at the utilisation stats of the device.

High CPU can be a result of excessive paging of resources. Something that happens when the OS runs short of memory. I would very much expect that you will see that happening on your configuration.

If you can afford it, go for a second Pi and only run the desktop on that, Node-RED on the original. You can also ditch the default desktop and go for something lighter weight.

If access is for emergencies only, the other thing you can do is set the Pi to default to boot only to the command line (e.g. no desktop) but know how to start and stop the desktop if needed. You can still SSH into the Pi and start the desktop remotely.

1 Like
#8

Or use a pi 4.

1 Like
#9

Thanks everyone. Just to clarify, I have no performance issues with the Pi when I run it headless! Access to the dashboard from other network devices (laptop, mobile, etc.) do not cause any high CPU load issues.
ONLY when using Chromium (or Midori) on that Pi to access the local node red dashboard, the CPU load jumps from about 2% to 60% (resp. 30% with Midori).
So, I don't fully understand why remote access to the dashboard doesn't cause any obvious load increase while showing the UI on a local browser causes havoc.

#10

Do you by chance run charts or other ui parts on the dashboard with frequent updates requiring redrawing of (part of) the page? That kind of load is happening on the computer that runs the browser. When you do that on a remote machine the source machine has no issues with it. If it runs from the same machine it has to do both tasks.

1 Like
#11

@afelix,
YES, that is the case!

image
image.png1459×707 50.9 KB

Is there such a thing as "tuning" the browser refresh rate in the pi (or the dashboard ui?).

THANKS!

#12

No. The browser is doing what you asked of it.

You can tune the chart to a degree:

image

If you need more than Dashboard can realistically deal with (especially given the limited resources on a Pi), you should consider a more targeted dashboard - probably not using the Dashboard which is very large indeed - or use something like an InfluxDB/Grafana combination to produce your dashboard.

1 Like
#13

actually, the penny dropped! You have provided me with the solution!

The graph screen was the "landing page" by accident!

The one that will be more relevant for my "emergency access" is a much simpler one - something like this:

image
image.png1015×393 10.2 KB

So, by simply changing the sequence of my screens, even with an "open browser" on the pi, the CPU load dropped back to ... nothing!

THANK YOU ALL for your input! I learned a lot!

3 Likes
#14

Just as a test, I decided to try out Midori to view one of my Pi and got this

image

Needless to say - my flow doesn't normally render like that :slight_smile:

Could make a good Where's Wally game though :slight_smile:

3 Likes
#15

Haha, that probably is how it would look after quaffing a bit too much Midori Melon liqueur.

1 Like