I've been trying to track down a RAM issue on my rpi3 B+. It is running Node Red only, standard sw load (LXDE, etc) otherwise, nothing else major. I do use Cepstral Swift for spoken voice messages (called via exec node) and MQTT (broker is running on NAS). When I look at top via CLI clearly Node Red is the largest memory user.
Here is a 24 hour view of RAM usage generated by msg.payload.memusage provided from node-red-contrib-os. I cannot figure out the odd usage behaviour, and sometimes it can get bad enough to freeze NR, sometimes for a few seconds, sometimes to lock-up. Drastic changes in usage occur often in the middle of the night (or late in the day) when virtually nothing is going on.
Any ideas or suggestions to track this down?
TIA
st
As example, I see about 27% RAM free right now and NR is at 9% (top). I haven't viewed top yet when it's really bad but the range I've seen for NR so far is ~8.5% to 14%. So I'm not sure it's NR causing the issue. I just don't know.
Remember that LInux tries to keep as much of the ram in use as possible by caching the disc and so on, so you should not normally have a lot of free ram. What makes you think that RAM usage is the problem?
What started me on this was a significant delay with the Cepstral swift speech executable (called thru NR exec node). Normally when I want some speech processed it occurs without delay. But there are times when it takes like 20 seconds before the speech is processed, or it never is. At first I thought the processor was over busy, but clearly it's not (not tasked hard at all), and it turns out the free RAM is always very low when I have problems.
But now I'm not even tracking that issue really, I'm trying to understand the odd behaviour of RAM as reported by the Node Red OS node.
I did a similar project where I got TTS audio data (for streaming to a PA system) but what I did was to compute a hash of the text and save a cached copy of the audio data to file (named as the hash). When the same text was required, I accessed the cached copy by the computer hash as a file name instead of asking the TTS engine to convert the same text to speech. Eventually, all the phases were cached to file, available immediately for streaming.
