WorkFlow burns all resources and returns "Unknown" error

Hi,
I installed a new version of n8n ([email protected]) but found that iterative data writing to MS SQL database doesn’t work. I have 10 similar WorkFlows and none of them works. The problem is somewhere in part “SplitInBatches-FunctionItem-MS SQL (call storedProcedure)”. WorkFlow also burns all available CPU resources and 3.6GiB of RAM.

Workflow:

Execution log:

The latest working version is 107.0. With this version, it took 30 seconds to save 1000 record to the database =>33 records/second. With 108.0 and later, it stores 1 record/second and after 30second everything stops. After a certain time, the status in the log changes from running to Unknown.

Resources from [email protected] to [email protected] (184% CPU + 47% RAM (3.6 GiB))


Resources [email protected] (55% CPU + 5% RAM (385MiB))

Try replacing the Batch(Empty) with a merge node in pass-through mode as i really dont understand why you are splitting the batches 2 times?

I don’t understand…
The fourth node is not “SplitInBatch”. It is IF with condition {{$node[“SplitInBatches”].context[“noItemsLeft”]}}

Oh sorry man, Completely saw it wrong

Very sorry to hear that you have problems! We did hear already from a few people that they run into issues with versions past 0.107.0. We are actively investigating and try to reproduce. Sadly is it however hard to fix a bug we are currently not able to reproduce. If you are able to create a simple version of your workflow that causes the same problem (one we can simply execute as is without any external dependencies like a DB) that would be immensely helpful.

Forget that. I was able to create a very simple workflow based on yours above which reproduces the problem. That runs in like 8 seconds on 0.107.0 but was still not done after like 3 min with 0.108.0 and I then killed. We will try to fix asap.

1 Like

Great. I’m glad to hear that…
And I’m glad that I was able to help solve the problem at least a little. :slight_smile:

Found now the code which causes the problem. We will try to fix in the next days. One thing you can do for now is to either roll back to 0.107.0 or keep on using the current version but set the environment variable EXECUTIONS_PROCESS=main.
That makes sure that the workflows run in the main process. That makes n8n much faster and improves the throughput and in this case also solves this problem as then no cross process communication is required (which is the reason for this problem).

We already did roll back to 0.107.0. We will also check your suggestion. Thanks.

Fix got released with [email protected]