Having done some tests I can confirm that is correct. It doesn't stop node-red from consuming additional memory if node-red demands it. In addition max old space is supposed to be redundant in nodejs 12+ as it is supposed to work it out based on the amount of memory available.
Which presumably means that @rko's system is asking for more and more memory, which on that scale is odd just for a few strings. Unless the array being build and kept in context is huge. @rko how big does the array get?
Apologies for the late answer @Colin. After your comment regarding file based storage, we switched to a "ring buffer" system which sets a size limit to the array of a several thousand value pairs per curve.
It's actually mentioned in the documentation, that a file based storage is being stored in the memory (still).
The two steps helped to make the system more stable:
-
Change the way timestamps are being produced, recommended by @TotallyInformation
-
Introduce a max capacity to the measurement data array (in the future, we might want this a bit more advanced by creating some sort of average instead of directly deleting historical data, and/or move data to a data base periodically)
1 Like
I guess that you know that this is exactly what InfluxDB is good for?
I thought about that, but I am not sure it is appropriate for a system with 500MB RAM. Also whether the long term storage would be appropriate for influx, though I have not asked about it.
I would not have considered running influx on a Pi Zero with an SD card, for example, with data being recorded at 5Hz.
I must say, the conversations here have been very helpful and interesting. And we are looking forward to more. Hopefully we will be able to help others too.
In this project, the amount of data being stored is not as big as it might seem. After each heating cycle we only store a summary (such as date&time, heating time, max temperature etc.). However, during PID tuning the dashboard will display the complete measurement data (5 Hz or even higher) . The plotly graph is an important tool to optimize the heating processes. If the engineer leaves the webinterface running or uses it for a long time, this might have led to a crash sooner or later. That's why we had to fix this problem.
For future projects with bigger amounts of data, a database system such as InfluxDB makes totally sense. The plan is to run the data base on another system since the mentioned controller is not as "powerful" or suitable for this task.
Should we move this post to another category, since it wasn't really a dashboard issue?
1 Like
Technically yes, but I think users encountering similar problems would expect to find it in the dashboard category, so maybe leave it here.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
