Inspecting/Capping (per-Node?) memory usage

Core Development Feature Requests
1

It has happened to me in the past that Node-RED just keeps allocating memory up to the point where the system can longer handle it. I'm talking about a memory-constrained system i.e. the Raspberry Pi.

I haven't been able to track it down properly, but I strongly suspect this might be due to nodes which do internal queuing, like:

  • node-red-contrib-ibm-watson-iot, if for some reason there's no connectivity available for a long time
  • delay node used for rate limiting, when the incoming rate is steadily higher than the output rate
  • also the serial request node which I recently added might suffer from the same problem

I do realize it is a problem with how the flow is designed and in many cases the proper solution would be to rework the flows. However, these are somehow edge cases which are not easy to detect at first.
Also, they may compromise the entire system, so I think a little aid from Node-RED itself might be in order, resulting in the whole system becoming more reliable.

Ideally, I would like to have a way to inspect and/or cap how much memory a node is using. I'm not at all familiar with how V8 and/or Node.js handle memory allocations: I don't believe there's a way to "attach" a context when memory is allocated, is there?

Failing that, perhaps what could be done would be to allow nodes with queuing to expose this information (i.e. current/max queue size, though in terms of messages, not bytes) in a uniform way. The delay node shows this in its status property; what I'm suggesting here is to expose this information with a standard, separate property.

How to "update current" and "honor max" would still be the node's responsibility, but then this information could be used in a homogeneous way (with a near-clone of the status node), e.g. to send an alarm when a threshold is exceeded.

These properties should logically belong:

  • to the actual node e.g. for the delay node
  • to the configuration node for the WIOTP and serial request node

How does that sound? Too much work compared to the potential gain?
(Keep in mind the whole system's stability is at stake here...)

Thank you!
Gerlando