I have tried accessing the dashboard via Chrome on my Windows 10 laptop and never had any issues - but then again I'm not running 24x7 as I am on the Pi.
I've pasted a screen shot of the offending dashboard below. The circled numbers I've added on to give some explanations.
This chart covers a 10 minute period with both the red and green lines updated every 60 secs. Total of 20 plots.
This chart covers a one hour period with both lines updates every 60 secs. Total of 120 plots.
This chart covers a 12 hour period with both lines updated every 60 secs. Total of 1440 plots.
These three meters are updated once every 60 secs.
The weather is updated once every 15 minutes.
The time is updated every 60 secs.
The room temperatures are updated 5 minutes.
To me, that's not a huge amount of plots or processing, particularly on a device with 8Gb of memory. If the esteemed audience here still think that's whats giving me the issues then I suppose I will have to write each of the captured measurements to a table and then plot an average of those entries on a timely period?
I agree, have you confirmed that the charts are definitely being updated only at the rate you believe? Add debug nodes showing what is going into the charts to make sure.
Also it would be worth running top on the pi to see whether there is an issue with the total amount of memory being used.
It is easy to slow down the data rate on the 12 hour one as a test. First use a node-red-node-smooth node to give you averaged readings over, say, a ten minute period, which will give you a value every 60 seconds which is the average over the last 10 minutes, and then feed that into a Delay node in Rate Limit mode to let one of those through every 10 mins, and feed that to the chart.
You will need a longer monitoring session on the Pi to look at memory utilisation over time leading up to a crash.
Impossible to know at the moment whether the out-of-memory issue is at the OS level or some limit within the browser.
In Chromium based browsrs, you can record a performance profile that shows you all of the events on a timeline. Mainly about tracing call stacks and understanding the performance down to function level but also shows changes to the Heap and CPU over time.
Or you can use the Memory tab to see the Heap usage and I/O rates live and can take snapshots over time. The snapshot gives a detailed breakdown of Heap use by object at a point in time. The statistics view is quite useful as it shows you what is hogging the Heap at the point of the snapshot. Here is an example from this page:
The containment view lets you start to analyse by specific objects and separate out extension Heap usage from specific windows and objects in a window:
One other thing to note - if you have any extensions installed, try creating a new profile in the browser with no extensions installed.
Interestingly, when looking at my own Dashboard weather view, I note that the snapshot reports a smaller heap usage = 14MB instead of 25MB for Discourse. However, the "Retained Size" for the actual Dashboard window is MUCH larger - over 1MB vs less than 1/2MB. I don't really know what the "Retained Size" means though.
This on a 16GB i7 Microsoft Surface Book 2 which is a bit of a beast.
Ah, just spotted D3 on that list so I'm guessing this is the Node-RED editor window rather than the Dashboard window. So if you do use the Memory snapshop, make sure you don't have any other tabs/windows open in the browser. Typically I have 10 or so Windows open containing maybe 100 tabs. And when working, I also have two other profiles open each with 1 window and maybe a dozen tabs each.
