Node-RED Global Context and Node.js Heap Memory Integration

Answer

The safest way to keep a single flow from draining the Node.js heap while still using the default in‑memory context store is to bound the data you place in global context and to monitor heap usage so you can act before the limit is reached.

Confirmed facts

• Node-RED’s default memory store puts every value assigned via global.get/set directly into the V8 heap, so its size contributes to process.memoryUsage().heapUsed.
• The V8 heap limit for a 64‑bit Node.js process is roughly 1.5 GB; exceeding it triggers a fatal "JavaScript heap out of memory" error.
• Node-RED can be switched to a file‑system or custom context store, but that moves all context data off the heap.

Likely explanation

Storing large JSON objects, arrays, or Buffers in global context increases heap consumption proportionally. If a single flow repeatedly adds data without removing stale entries, heap usage will grow until garbage collection can no longer keep up, leading to longer GC pauses or an OOM crash that affects the entire Node‑RED instance.

Steps to bound per‑flow impact without changing the store type

1. Use bounded data structures – instead of pushing raw arrays, wrap them in an LRU or fixed‑size queue (e.g., a simple function that drops the oldest entry when a length threshold is crossed).
2. Enforce size limits in function nodes – before calling global.set(key, value), check an approximate size (e.g., JSON string length or Buffer.byteLength) and refuse or truncate if it exceeds a per‑flow threshold.
3. Periodic cleanup – add a timed function node (inject node set to repeat every few minutes) that iterates over known global keys and removes entries older than a TTL or that exceed a size budget.
4. Monitor heap usage – expose process.memoryUsage() via a debug node or the Node‑RED admin API (GET /context/global when using the memory store) and set an alert when heapUsed approaches, say, 80 % of the configured --max-old-space-size.
5. Limit Node‑RED heap at startup – launch Node‑RED with a conservative --max-old-space-size (e.g., 512 MB) so that any runaway growth triggers an OOM early, making the problem visible during testing rather than in production.

Verification you can perform

# 1. Record baseline heap
node -e "console.log(process.memoryUsage().heapUsed)"
# 2. Inject a 10 MB JSON object into global context via a function node
# 3. Record heap again and confirm the increase (~10 MB)
# 4. Reduce heap limit and test OOM: node --max-old-space-size=100 red.js
# 5. Observe the fatal error when stored data exceeds the limit.

If you need to know the exact size of a particular global key to tune your limits, ask for that measurement; otherwise the steps above apply.