Do you have issue n8n 0.236.0 since database update

أسئلة
24

Hi,

I finaly made a rollback to 0.231.1 because we had too much performance issues since the update with the new database schema!

What I can see in big difference between 0.231.1 and 0.236.x is that the 0.236.x have much more database sessions (especialy active sessions that are nearly nulle in 0.231.1 and around 120 in 0.236.x) than 0.231.1 howover workflows that are executed are the sames. CPU with 0.231.1 is normal instead of 0.236.x all my CPU were at 100% all the time.

And last point but it’s because of performance issues, is the number of workflows that are executed in the same time I’m now back to 70/100 workflows instead of 300/500 with 0.236.x but I’m pretty sur that is because performance issues with postgres.

Thanks for your help but for now we can’t update due to this performances issues when there is heavy loads.

26

Hi @Kent1, unfortunately it’s really hard to help you without a scenario letting us reproduce the problem. The htop screenshots you have shared show a high CPU load, but it’s not clear to me what exactly is causing this. Are you perhaps simply having a large database with lots of executions? In this case, the database migration required by n8n@0.234 (and later versions of course) will be a very expensive operation.

In this case, you might want to consider removing execution data before proceeding with the upgrade.

Are there any hints in your n8n server logs about slow queries or other errors?

27

Hello @MutedJam,

Thank you to taking time to try to help me with my issue.

In fact, I upgraded to 0.236.0 during approx 10 days (the migration to 0.231.1 to 0.236.0 was not the problem). I delete all my execution_entity before the upgrade. The problem comes after the migration, we had lots of crash of the main instance and lot of performance issues during spike of activity. The docker postgres took all my CPU.

The main difference is the active connection. As you can see bellow the green line is close to null (v0.231.1), but when I was in 0.236.0 the active sessions was arround 120/150.

image
image702×205 10.4 KB

28

Hi Kent1, we’ve discussed this internally and were wondering if this could come down possibly using the own executions process setting.

When re-trying the upgrade, can you try setting the EXECUTIONS_PROCESS=main environment variable and confirm if this makes a difference for you?

29

Hi @MutedJam,

In my docker compose I didn’t set up this env varibale EXECUTIONS_PROCESS. Is by default the value is to own or to main ?

30

Indeed, by default it would have been own for n8n versions before v1 you you’d need to add it in order to verify if this has any impact.

31

Thank @MutedJam

I will come back to you when we will try a new update (not before september I guess because of hollidays periods).

32

@MutedJam I just check the documentation to understand the difference between own and main.

An I see when we use “queue” mode (that my case) n8n ignores any EXECUTION_PROCESS setting and uses main. So the point is somewhere else.

33

Hi @Kent1, this is a suggestion made by our engineering team. So far no one is 100% sure why you would be seeing this behaviour based on the information provided, and it was suggested this might be worth a shot.

34

@Kent1 We suspect the issue that might be causing these problems was a missing index on one of the new tables. A fix just got merged here.
Once this is out in the next release, I hope it will resolve the high CPU usage problem.

35

Hello @netroy,

Thank you for this information.

I will try the new version as soon as I can, but we are careful now since the issues that we had with the last update.

I will let you know when we will do the update and if our problem is solve or not :wink:

Thank again.

36

By The Grace of G-D.

Hi,
I Just updated to the next version (1.1.1) and the CPU had finally found some peace…
Only for a short while because it is back to 100%.

Also, i have a different issue that keeps popping up:

postgres_1  | 2023-08-01 23:22:06.779 UTC [68] WARNING:  database "XXXXXX" has a collation version mismatch
postgres_1  | 2023-08-01 23:22:06.779 UTC [68] DETAIL:  The database was created using collation version 2.31, but the operating system provides version 2.36.
postgres_1  | 2023-08-01 23:22:06.779 UTC [68] HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE XXXXXX REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
postgres_1  | 2023-08-01 23:22:06.779 UTC [68] CONTEXT:  parallel workerThis text will be hidden

Any idea how to fix this?

37

Hi @yossi

Can you tell us witch version of postgres you are using please ?
From my side I user postgres 11 with docker maybe I have to update to 15 ?

38

psql (PostgreSQL) 15.3 (Debian 15.3-1.pgdg120+1)

39

@yossi did you update postgres as well?

41

Hi,

I Didn’t.
Looks like it was upgraded automatically.

Yesterday, the UI just stopped responding and the CPU was on 100% all the time so i exported the workflows and credentials, recreated the instance and now everything is working perfectly!

The 2 major issues with the import is that the credentials export/import worked but the credentials are not working and i had to recreate them.
and that some of the workflows were created by another user and he now doesn’t have access to them…
But that’s for another ticket.

42

New version n8n@1.2.1 got released which includes the GitHub PR 6797.

43

Hi,

I will try this version soon and come back to you to let you know if it’s ok or not :+1:

Thank you for your job and your reactivity.