Number of executions per hours: 132
Number of workflows: 23
Cumunity Edition
n8n Version 1.26.0
location / {
proxy_pass http://127.0.0.1:5678; # Ensure this IP and port are correct
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade'; # For WebSocket support, otherwise remove
proxy_http_version 1.1;
}
Starting latest 2-3 weeks i get lots of errors and slow interface opening, I check server performace is fine. I have an 2vCPU 8GB RAM, 80GB SSD server so not sure why recently i get so slow since server peronce seems fine.
NGXIN:
It looks like your topic is missing some important information. Could you provide the following if applicable.
- n8n version:
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app):
- Operating system:
In nginx logs i get this:
[error] 426101#426101: 13262 recv() failed (104: Unknown error) while reading response header from upstream, client: 162.158..*, server: site.com, request: “GET /rest/executions?filter=%7B%7D&lastId=213057&limit=10 HTTP/1.1”, upstream: “http://127.0.0.1:5678/rest/executions?filter={}&lastId=213057&limit=10”, host: “site.com”, referrer: “https://site.com/executions”
I also tried to access n8n without any reverse proxy direct ip and port, and all the above problems can be replicated. can you help me?
I fixed this, it was because of the startup environments i was using to keep database small:
-e DB_SQLITE_VACUUM_ON_STARTUP=true -e EXECUTIONS_DATA_PRUNE=true -e EXECUTIONS_DATA_MAX_AGE=336 -e EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000
If you have same problem my sugestion is to remove this envirments variables and just find an other way to keep database small, what i did i migrated to postgresql from sqlite as i think is much easier to partially delete some information copared to sqlight, but i might be wrong 
so better remove manually some informations from tables with lots of mb
