Why Raspberry pi becomes slow while running for a long time?

I am trying to use Raspberry pi for industrial automation. I am controlling some machines according to some logical condation based on sensor data. I am treegaring Raspberry pi pines to control the machines.
I have 4-5 flows and approx 200+ nodes.
There is one dashboard tab and I am using 2 chart, showing live sensor data and some other user interfaces. Also using 3-4 database node to store and retrive data from database.
I am using Raspberry pi 4 Model B, Ram 4 GB. Using the latest Node red and node js.
The SD card size is 32 gb.
The Pi becom slowing down after 10-15 hours. But after restarting, it become normal.

Is there any way to clear the ram or temp file automatically or is there any other way to make it normal without restarting the pi?

Check to see if SWAP is being used, that is typically a major impact on performance. What version of OS, NPM, Node Red, Node.js, etc. are you running? have you run top to see which processes are drive CPU and memory use?

I have several Pi devices running similar loading, even Pi Zeros with a quite a bit running on them, and as long as I avoid engaging SWAP space, performance is ok.

If you have a flow that is looping oddly it can leak resources, drive CPU load, etc.

How can I avoid engaging SWAP space?
I didn't check the processes.

Typically you don't want to disable SWAP, because it can keep Pi online for unexpected resource needs. It is better to scale your flows and resource use to avoid engaging SWAP.

Near the bottom of this web page, is steps to disable SWAP.

I will try this out. Thanks!

It may well be the charts causing the problem.
What time range have you got for the charts, what sample rate are you using, and how many lines on each chart? Work out the total number of days points on the charts, each time a new sample is added all those points have to be shuffled down the chart, which can be a large load, particularly on the browser. If that is the problem then the solution is to reduce the sample rate going to the charts.

There are only 2 charts for 2 sensor values. The values are coming to each 5-sec interval. Here is the Dashboard UI:


(The sensors are not connected right now)

You didn't give the time range configured for the charts.

Here it is.

I see the time range is 24 hours. Did you do what I suggested, to work out the total number of points on the charts? You have a 24 hour range (1440 minutes) and are adding data points at the rate of 12 per minute. So once the chart has filled up that is 17280 data points. With two charts and two lines per chart that is 69120 points that the browser has to shuffle down the chart every five seconds. Even with a Pi 4 I imagine that is quite a load. This matches your symptom in that it gets worse as the chart fills up with data. There is not much point having more data points across the chart than there are pixels. It is not clear from your image where the charts are but I guess they are quite small. If they were, for example, 150 pixels across then that means there is no point having much more than 150 data points in the 24 hour period which would be one sample every 5 or 10 minutes. So I suggest either drastically slowing down the rate of data going to the charts (you can use a Delay node in Rate Limit mode for that) or reduce the time range of the charts, or a combination of both.

1 Like

Thanks for such a descriptive explanation. I am gonna change according to your suggestion. As the machines will run up to 8-10 days continusly, can you please suggest any other changes that might help. Thanks!

Make sure that you are not running a gui desktop on the Pi unless you absolutely need it, that is a really killer to performance.

Really though you need to start monitoring the device to work out what is causing the slow-down. At the moment, you don't have hard data to work with.

At the very least, install atop or htop and monitor the Pi when it starts to slow down, share some of the data with us so that we can see what is happening. Installing glances is even better though it is itself fairly large - but that doesn't really matter since we are just trying to find out what is happening.

Better still if the pi is going to be a critical component, you should consider a more industrial monitoring solution. There are plenty of commercial products but you may be able to simply use something like Telegraf to capture the Pi's system performance data. Typically, you will send that data on to a logging service and create 1 or more dashboards off that logging service.

For my home systems, I run Telegraf, InfluxDB (for the logging) and Grafana for the dashboards. Even on a Pi2 B+ (512k RAM), it is perfectly feasible to have NR, Telegraf, InfluxDB, Grafana and Mosquitto running together as long as you don't keep too much data in InfluxDB and are sensible about NR flows.

In a commercial environment, you would probably be using Splunk or some other log aggregation and analytics tooling and might use SNMP rather than Telegraf.

Can you offload the monitoring to a different device? Typically the device that does the sampling, should not be the device that does the reporting. You want to avoid the 'observer effect' meaning the very act of watching, change the results of the experiment, so to speak.

For example, this is why, many, for one reason or another, use ESP8266/ESP32 modules to collected data, and use a Pi device to collect and report results. Having one device measure and forward data is typically a light weight tasking. I use not only ESP modules but PiZeros for data collection, or environment manipulation... smart wifi devices, bridges, servers, motors, relays, etc. But everything uses MQTT to forward data, or receive commands.

I once used direct socket transport, since I had a lot of python based stuff, and even C based programming, but as I have added NR to my environment, I have been retiring most of the Python/C based elements in preference to NR, especially the data collection and analysis aspects. But some of the raw control or data elements continue to be Python/C based for now.

Oh, I use SNMP a lot for devices that have limited interfacing... all my WIFI routers for example support SNMP, so that makes monitoring them straight forward with NR as well. LOL... when family are visiting, man, do they hammer my connectivity.

If it was running ok for several hours but then slowed down then I think it highly likely that sorting the charts problem will fix it for you.

Yes, very true. In my case of course, it doesn't really matter. In a commercial case, might be different. It probably depends on whether the deployed device is one of many in a managed environment or a singleton for each customer/location.

Certainly, you would want the reporting side to be separate in a live environment. But capture is still going to be local of course.

I will try every possible soluation. The devices are already diployed in the factory. The logical operations are smoth, only the dashboard becoming slow based on time. Thanks for the tips. I was thinking about uibuilder dashboard. I don't know it will help or not.

Is that still happening now you have reduced the number of points on the charts?

Only the dashboard slows? Not 'node' in general or in total?

The dashboard is slow and sometimes the flows become slow.