There is no guarantee that the node that happened to try to allocate some additional memory and failed is the one that is actually consuming all your free memory.
I have never found a particularly satisfactory way of tracking down these sorts of issues. But I have spent a lot of time trying.
Ultimately you need to consider any parts of your flows handling large messages, or lots of small messages.
There are lots of articles online on understanding node.js memory usage from a heap dump; that may give you some idea of what is eating the memory.
Are there any known memory issues around filter node or trigger node.
After trial and error - i have managed to limit my investigation to a short flow which i have which uses the above.
The flow does below (high level)
Gets input as msg.payload as X and msg.topic as Y.
(The above input keeps coming in continuously till there is data on disk - if checks if there is data on disk - create array loop over array and send as input on msg,payload )
For each input - send filter node (set to block unless value changes for msg.payload) - which in turns feeds to trigger node (both filter and trigger nodes are set to process per topic)
When there is no more input left - trigger node would send a signal after waiting for certain time.
What i typically see is when i keep above flow out of picture i dont get heap error.
I am talking about a volume of 6000 or so messages on 1 topic with multiple topics running in parallel.
Any suggestions if these 2 nodes can run into heap issues ?
(I am also check to change the above design completely)
As it stands, there is not enough to go on. For example you didn't state how many messages over what time frame, you haven't specified the size of data in the messages etc etc.
Being a prod system - its tricky. But what we did see is since we bypassed the small flow i mentioned above the heap issue has come down drastically.
Previously we had a flow hitting this small segment of flow (mentioned in Steps 1-3 above) , with 30-40k messages . There was no need to . So we removed it from that flow. The moment this was done - we moved to heap being generated once in 2-3 days against 1 daily.
Today we have around 12 flows running daily concurrently each with its own topic.
Each day is fresh run. The topic changes per day.
The number of cumulative messages across all topics for a day would be around 10000 - 12000 messages.
The topic which has max messages has around 6000 messages. Size per message is around 3000 bytes.
Each message hits this segment of flow (filter + trigger - see steps 1-3 in earlier note). The flows run over a few hours.
The flow 6000 messages runs around for 2 hours.
Generally when the heap is seen - it is this flow which is still processing messages.
The challenge with that approach would be then what finishes in few hours today may take double or 3 times the time. The flows feed data to other non NR processes, which run in parallel and complete by their tasks.
What device are you running node-red on, how much ram has it got, and exactly what command line are you using to run it?
In the critical flow, make sure you have not got any extra nodes, including debug nodes. Try and eliminate any places where you have two or more wires coming from a single output, as each time that happens the message will be cloned, doubling up the amount of memory required.
You say that 6000 messages takes 2 hours, which is about 1 second per message. What is it that takes a second to perform? Is it complex processing in nodes or are you calling an external process, such as a database or http api for example?
[edit] In fact you say that if you do it sequentially it takes 4 to 5 times as long, so each one takes 4 or 5 seconds.