Memory leak, none of the existing answers help

I have been using node-red for a basic flow-builder use-case. For that purpose, I have hidden all the nodes I don't need and created 4 extra nodes. It had been working well for the past 3 weeks until this week whenever I open the site it rapidly increases the memory as much as 8 GB before crashing within a minute (Not sure about the exact change that triggered this).
Node-red version: 1.2.8
Node version: 13.6.0
Docker version: 19.03
Docker image: Re-built from the alpine script provided in the node-red docker repo

None of the existing answers in the forum have helped in my case (at least the ones I have looked at, on a time crunch here). There is no use of context in any of the nodes. Not using the rbe node. I have even updated the node version as per some discussions in the forum. Please let me know if any more specifications are needed to elaborate the query. Any help will be appreciated.

Edit: I have also created a button on the header, beside the deploy button that sends the deployed flows using an API call, on click. If this needs to be optimised, do elaborate on how it can be changed.

It may not be related, but you are using an unsupported and obsolete version of nodejs. I suggest upgrading to 14.x

Have you modified your flow recently? Perhaps created a loop?

What other nodes are you using? any large DB queries for example?

Does node-red still crash if you disable all (or parts) of your flows?

other thoughts.
You didnt say but as V1.2.8 was only released yesterday, you have obviously updated recently. Was this happening prior to V1.2.8 (with the exact same flows)?

Yes, I updated the version to check if it would solve the problem

Haven't created a loop inside the flow, but yes the new nodes that I have added have some computing, for example the editprepare section of my nodes require functions to render specific inputs (And as per my knowledge, this must not affect the memory usage a lot)

The only inbuilt nodes (core nodes) I am using are inject, debug, switch. The rest are custom, in addition to the python nodes which I had installed from the community. So no DB queries.

Should I change the version back to 1.2.6 (the one I started with)?

Thanks. I will update the version and check if it solves the issue :slight_smile:

Consider the symptoms.

  1. It worked without problems for weeks.
  2. You made some changes and now it has problems.
  3. Conclusion?

I suggest going back to the previous versions of those nodes to see if that fixes it.

Any other hidden loops inside your nodes ? Eg things like reconnections to other services that loop on error/retry. ( where for some reason the service is now unavailable)

Nope. There are switch statements, but no reconnection attempts or unchecked loops.
This might be related ->
In my custom js file (external js file I had used to create the extra button beside deploy), I had added the condition to check for the other core nodes and remove them when they are loaded, because I had red in the forum that to remove those nodes I might have to change the red.js file and I did not want to change it. This change was done 2 weeks ago though and it didn't create a problem back then. But do you think it can cause the leak?

I did check them. Even removed a few nodes that I had created to check if they might have caused the issue, didn't work. Nonetheless, I will give it another run. Uninstalling all the new nodes and checking now.

Didn't help :frowning:

Revert to your last working backup and then work forwards from that till the problem re-appears.

Thanks, I'll do that.
Also, unrelated- Is there a document where I can check all the RED functions? Or is there some specific page in the documentation that I had missed by chance?

Made some progress. It's gonna be complex to explain it here but I am gonna try.
So in order to remove the sections and the nodes I didn't need, this is the code block I had used:

function wait(){
if (window.$ && document.getElementById("red-ui-palette-container")!=null && document.getElementById("red-ui-palette-container-network") !=null) {
            var comm_need= ["inject", "debug", "function", "switch", "python3-function", "catch"];
            var comm_el=document.getElementById("red-ui-palette-common");
            var func_el= document.getElementById("red-ui-palette-function");
            for(let x=0; x<comm_el.children.length; x++){
                if( !comm_need.includes(comm_el.children[x].getAttribute("data-palette-type"))){
            for(let x=0; x<func_el.children.length; x++){
                if( !comm_need.includes(func_el.children[x].getAttribute("data-palette-type"))){
        } else {
            inter=setInterval(function () { wait(); }, 1000); // check every 100ms

Not the most optimal perhaps, but it did work. However, it kept giving an error that it could not remove null at "red-ui-palette-container-shelly". So I assumed that shelly container had not loaded while the others had. So I modified the condition to check if "red-ui-palette-container-shelly" DOM element had loaded. This is when the problem began, now that I backtrack it.

I reverted the condition to the one I mentioned in the code block and yay the memory issue got resolved, but now it's not removing any other container (basically all the other nodes are now visible).
Is there a better way remove all the core nodes which aren't required? I have been asked to remove them at any cost and clearly this solution cannot be relied upon

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.