Risolvere l’errore n8n "Existing execution data is too large": guida completa per istanze sulla propria infrastruttura

Il self-hosting di n8n offre esecuzioni illimitate dei flussi di lavoro e controllo completo, ma flussi complessi con grandi insiemi di dati possono generare errori frustranti che devi risolvere nella configurazione del tuo server. Se visualizzi «Please execute the whole workflow, rather than just the node. (Existing execution data is too large.)» quando provi a testare singoli nodi, hai raggiunto il limite di dimensione del payload. Ti mostreremo come individuare il problema, risolverlo e ottimizzare il limite per installazioni n8n pronte per la produzione.

Il problema: quando i test dei flussi di lavoro non funzionano

Hai correttamente configurato la tua istanza n8n e impostato webhook affidabili, ma ora stai costruendo flussi di lavoro più sofisticati che elaborano file, risposte API di grandi dimensioni o insiemi di dati. Tutto funziona quando esegui il flusso completo, ma non appena provi a testare un singolo nodo o a eseguire solo una parte del flusso, n8n mostra il temuto messaggio di errore.

Questo accade perché n8n impone un limite predefinito di 16MB ai dati delle esecuzioni parziali: è adeguato per flussi semplici, ma diventa un collo di bottiglia appena si elaborano volumi di dati reali.

Cosa risolverai

Al termine di questa guida avrai:

• ✅ Un limite di dimensione del payload aumentato da 16MB a 256MB o a un valore personalizzato
• ✅ Esecuzioni parziali funzionanti per flussi complessi con grandi insiemi di dati
• ✅ Risorse allocate correttamente tenendo conto dei limiti di RAM del server
• ✅ Un sistema di monitoraggio per seguire nel tempo l’utilizzo della memoria
• ✅ Una configurazione pronta per la produzione che gestisce flussi di elaborazione dei file
• ✅ Procedure di backup e rollback per le modifiche alla configurazione

Prerequisiti

• Un’installazione n8n funzionante (preferibilmente seguendo la nostra guida di configurazione su Hetzner)
• n8n in esecuzione in container Docker
• Accesso SSH al server
• Conoscenze di base delle variabili d’ambiente di Docker Compose
• Almeno 3GB di RAM disponibile (consigliati per un limite di payload di 256MB)

Comprendere la causa del problema

Perché n8n sulla propria infrastruttura ha limiti di payload

Quando esegui solo una parte del flusso per testare singoli nodi, n8n deve serializzare e trasmettere al backend lo stato e i dati del flusso di lavoro. Sono inclusi:

• Tutti i dati in ingresso dai nodi precedenti
• La logica del flusso di lavoro e le configurazioni dei nodi
• Il contesto di esecuzione e le variabili
• I dati binari e il contenuto dei file

Il valore predefinito N8N_PAYLOAD_SIZE_MAX=16 (16 MiB; il valore è espresso in MiB) è stato pensato per risposte API tipiche ed elaborazioni semplici. I flussi di lavoro moderni, tuttavia, gestiscono spesso:

❌ Scenari comuni che superano 16MB:

• Caricamento ed elaborazione di file (PDF, immagini, fogli di calcolo)
• Risposte API di grandi dimensioni dalle fonti di dati
• Trasformazioni di dati in blocco
• Flussi di lavoro in più passaggi con dati accumulati

✅ Cosa cambia dopo la correzione:

• Le esecuzioni parziali funzionano con grandi insiemi di dati
• I flussi di elaborazione dei file diventano testabili
• È possibile eseguire il debug di trasformazioni complesse nodo per nodo

La configurazione mancante

La soluzione è la variabile d’ambiente N8N_PAYLOAD_SIZE_MAX, che imposta la dimensione massima del corpo delle richieste in MiB, inclusi i dati inviati dall’editor per le esecuzioni parziali. Quando una richiesta supera il limite, n8n risponde con HTTP 413 e l’editor mostra questo errore. Su n8n Cloud, n8n gestisce questa impostazione per te; le istanze sulla propria infrastruttura usano il valore predefinito prudenziale di 16 MiB.

Passaggio 1: diagnosticare la configurazione attuale

Verificare le risorse del server

Prima di aumentare i limiti del payload, verifica che il server possa gestire allocazioni di memoria maggiori:

# Check available memory
free -h

# Check current Docker container memory usage
docker stats --no-stream | grep n8n

# Check total system resources
htop

Requisiti di memoria:

• Limite di payload di 64MB: almeno 1GB di RAM disponibile
• Limite di payload di 128MB: almeno 2GB di RAM disponibile
• Limite di payload di 256MB: almeno 3GB di RAM disponibile

Individuare il limite attuale

Verifica se N8N_PAYLOAD_SIZE_MAX è configurata:

# Navigate to your n8n directory (adjust path as needed)
cd /opt/n8n

# Check current environment variables
cat docker-compose.yml | grep -A 30 "environment:"

# Look for payload size configuration
grep "N8N_PAYLOAD_SIZE_MAX" docker-compose.yml || echo "Not configured - using 16MB default"

Riprodurre la condizione di errore

Crea un flusso di lavoro di test per riprodurre il problema:

1. Apri l’interfaccia di n8n
2. Crea un flusso di lavoro con un insieme di dati di grandi dimensioni (ad esempio, un nodo HTTP Request verso un’API che restituisce >16MB)
3. Prova a eseguire solo un nodo a valle
4. Verifica che compaia l’errore «Existing execution data is too large»

Passaggio 2: risolvere il problema principale aumentando la dimensione del payload

Per una singola istanza n8n

Se hai una sola installazione n8n:

cd /opt/n8n

# Create backup first
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)

# Edit the configuration
nano docker-compose.yml

Aggiungi la variabile d’ambiente N8N_PAYLOAD_SIZE_MAX alla configurazione esistente:

version: '3'

services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - NODE_ENV=production
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
      - N8N_EMAIL_MODE=smtp
      - N8N_SMTP_HOST=mailserver
      - N8N_SMTP_PORT=25
      - N8N_SMTP_SSL=false
      - N8N_SMTP_USER=
      - N8N_SMTP_PASS=
      - [email protected]
      - N8N_TRUST_PROXY_HEADER=true
      - N8N_RUNNERS_ENABLED=true
      - WEBHOOK_URL=https://n8n.yourdomain.com
      # 🔧 ADD THIS LINE - Increases payload limit to 256MB (value in MiB)
      - N8N_PAYLOAD_SIZE_MAX=256
    volumes:
      - ./data:/home/node/.n8n
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.n8n.rule=Host(`n8n.yourdomain.com`)"
      - "traefik.http.routers.n8n.entrypoints=https"
      - "traefik.http.routers.n8n.tls.certresolver=letsencrypt"
      - "traefik.http.services.n8n.loadbalancer.server.port=5678"

networks:
  proxy:
    external: true

Per più istanze n8n

Se esegui più istanze n8n, aggiorna ciascuna di esse:

# First instance
cd /opt/n8n
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)
sed -i '/N8N_RUNNERS_ENABLED=true/a\      - N8N_PAYLOAD_SIZE_MAX=256' docker-compose.yml

# Second instance (adjust path as needed)
cd /opt/n8n-team2
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)
sed -i '/N8N_RUNNERS_ENABLED=true/a\      - N8N_PAYLOAD_SIZE_MAX=256' docker-compose.yml

Riavviare i container

Applica le modifiche:

# For single instance
cd /opt/n8n
docker compose down && docker compose up -d

# For multiple instances
cd /opt/n8n
docker compose down && docker compose up -d
cd /opt/n8n-team2
docker compose down && docker compose up -d

# Verify containers are running
docker ps | grep n8n

Passaggio 3: verificare la correzione

Controllare i log dei container

Verifica che i container si siano avviati correttamente:

# Check main instance logs (adjust container name as needed)
docker logs n8n-n8n-1 --tail 20

# Check for any startup errors
docker logs n8n-n8n-1 | grep -i "error\|failed\|warning"

Testare l’aumento della dimensione del payload

Torna al flusso di lavoro di test che non funzionava:

1. Apri il flusso di lavoro con l’insieme di dati di grandi dimensioni
2. Prova a eseguire un singolo nodo a valle
3. Verifica che l’errore «Existing execution data is too large» non compaia più
4. Conferma che le esecuzioni parziali funzionino correttamente

Monitorare l’utilizzo della memoria

Tieni sotto controllo le risorse del sistema dopo la modifica:

# Monitor memory usage over time
watch -n 5 'free -h && echo "--- Docker Stats ---" && docker stats --no-stream | grep n8n'

Passaggio 4: ottimizzare per il proprio server

Dimensioni consigliate del payload in base alla RAM del server

Scegli la dimensione del payload adatta al tuo hardware:

# For servers with 2GB RAM or less
- N8N_PAYLOAD_SIZE_MAX=64   # 64 MiB

# For servers with 4GB RAM  
- N8N_PAYLOAD_SIZE_MAX=128  # 128 MiB

# For servers with 8GB+ RAM
- N8N_PAYLOAD_SIZE_MAX=256  # 256 MiB

# For high-performance servers with 16GB+ RAM
- N8N_PAYLOAD_SIZE_MAX=512  # 512 MiB

Calcolo dell’utilizzo della memoria

Stima i requisiti di memoria:

# Calculate safe payload size (should be <20% of available RAM)
echo "Available RAM: $(free -h | awk 'NR==2{print $7}')"
echo "Current payload limit: $(docker exec n8n-n8n-1 env | grep N8N_PAYLOAD_SIZE_MAX || echo '16 (default, MiB)')"

# Monitor actual usage during large workflow executions
docker stats n8n-n8n-1 | grep -E "MEM|n8n"

Risoluzione dei problemi comuni

Problema: il container non si avvia dopo la modifica della configurazione

Sintomi:

• Il container termina subito dopo l’avvio
• Stato «OOMKilled» in Docker
• Il server non risponde più

Soluzione:

# Check container exit reason
docker logs n8n-n8n-1

# Reduce payload size if out of memory
cd /opt/n8n
sed -i 's/N8N_PAYLOAD_SIZE_MAX=256/N8N_PAYLOAD_SIZE_MAX=64/' docker-compose.yml
docker compose up -d

Problema: gli errori di dimensione del payload persistono

Sintomi:

• L’errore persiste dopo la modifica della configurazione
• La variabile d’ambiente sembra non avere effetto

Soluzione:

# Verify environment variable is set correctly
docker exec n8n-n8n-1 env | grep N8N_PAYLOAD_SIZE_MAX

# If missing, recreate container with force
docker compose down
docker compose up -d --force-recreate

# Check if the value is being read
docker logs n8n-n8n-1 | grep -i payload

Problema: peggioramento delle prestazioni del server

Sintomi:

• Tempi di risposta più lunghi
• Utilizzo elevato della memoria
• Utilizzo crescente del file di swap

Soluzione:

# Monitor system performance
vmstat 1 5
iostat -x 1 5

# Check swap usage
swapon --show

# Reduce payload size if needed
# From 256MB to 128MB
sed -i 's/N8N_PAYLOAD_SIZE_MAX=256/N8N_PAYLOAD_SIZE_MAX=128/' docker-compose.yml
docker compose down && docker compose up -d

Configurazione avanzata

Istanze separate per dimensioni diverse del payload

Il limite si applica a ciascuna istanza n8n, non al singolo flusso di lavoro. Gli utenti esperti possono valutare istanze separate con limiti diversi:

# High-capacity instance for file processing
n8n-files:
  image: n8nio/n8n:latest
  environment:
    - N8N_PAYLOAD_SIZE_MAX=512  # 512 MiB
    - N8N_HOST=files.yourdomain.com

# Standard instance for regular workflows  
n8n-standard:
  image: n8nio/n8n:latest
  environment:
    - N8N_PAYLOAD_SIZE_MAX=64   # 64 MiB
    - N8N_HOST=workflows.yourdomain.com

Limiti delle risorse dei container

Imposta limiti di memoria espliciti per evitare il sovraccarico del sistema:

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - N8N_PAYLOAD_SIZE_MAX=256
    deploy:
      resources:
        limits:
          memory: 2G      # Maximum memory usage
        reservations:
          memory: 1G      # Soft reservation, not a hard guarantee
    # ... rest of configuration

Monitoraggio dell’utilizzo del payload

n8n non riporta direttamente la dimensione del payload, quindi configura invece avvisi sull’utilizzo della memoria del container. Questo script presuppone che docker stats riporti la memoria in MiB:

#!/bin/bash
# Create monitoring script: /opt/monitor-payload.sh

CONTAINER_NAME="n8n-n8n-1"
MEMORY_LIMIT_MB=1500  # Alert if memory usage exceeds this

CURRENT_MEMORY=$(docker stats --no-stream --format "{{.MemUsage}}" $CONTAINER_NAME | cut -d'/' -f1 | sed 's/MiB//')

if (( $(echo "$CURRENT_MEMORY > $MEMORY_LIMIT_MB" | bc -l) )); then
    echo "WARNING: n8n memory usage high: ${CURRENT_MEMORY}MB" | logger
    # Add notification logic (email, Slack, etc.)
fi

Considerazioni sulla sicurezza

Protezione dai DoS basati sul consumo di risorse

Limiti di payload elevati possono essere sfruttati per attacchi. Limita la dimensione delle richieste nel reverse proxy, ma mantieni tale limite (in byte) pari o superiore alla dimensione impostata da N8N_PAYLOAD_SIZE_MAX, altrimenti il proxy rifiuta le richieste grandi con HTTP 413:

# Add to Traefik labels for request size limiting
labels:
  - "traefik.http.middlewares.payload-limit.buffering.maxRequestBodyBytes=268435456"  # 256MB max request, matches N8N_PAYLOAD_SIZE_MAX
  - "traefik.http.routers.n8n.middlewares=payload-limit"

Limiti specifici per flusso di lavoro

Valuta restrizioni basate sul flusso di lavoro:

# Monitor workflows with large payloads
docker exec n8n-n8n-1 n8n execute --help

# Log large executions
(crontab -l 2>/dev/null; echo "*/10 * * * * docker logs n8n-n8n-1 | grep -i 'payload\|memory' >> /var/log/n8n-payload.log") | crontab -

Ottimizzazione delle prestazioni

Gestione dei dati binari

Per i flussi di elaborazione dei file, ottimizza l’archiviazione dei dati binari. Tieni presente che N8N_BINARY_DATA_TTL non ha effetto da n8n 1.9.0; n8n elimina i dati binari quando rimuove le vecchie esecuzioni:

environment:
  - N8N_PAYLOAD_SIZE_MAX=256
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem  # Store files on disk, not in memory
  - N8N_BINARY_DATA_TTL=1440                 # Clean up files after 24 hours

Ottimizzazione del database

Payload di grandi dimensioni possono influire sulle prestazioni del database:

# Monitor database size growth
du -sh /opt/n8n/data/

# Clean up old executions more aggressively
# Add to docker-compose.yml environment:
# - EXECUTIONS_DATA_MAX_AGE=168  # 7 days instead of default 14
# - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000

Backup e ripristino

Strategia di backup della configurazione

Esegui sempre un backup prima di apportare modifiche:

#!/bin/bash
# Create backup script: /opt/backup-n8n-config.sh

BACKUP_DIR="/opt/backups/n8n-configs"
mkdir -p $BACKUP_DIR

# Backup all n8n docker-compose files
for instance in n8n n8n-team2; do
    if [ -d "/opt/$instance" ]; then
        cp "/opt/$instance/docker-compose.yml" "$BACKUP_DIR/${instance}-$(date +%Y%m%d_%H%M).yml"
    fi
done

# Delete backups older than 10 days
find $BACKUP_DIR -name "*.yml" -mtime +10 -delete

Procedura di rollback rapido

Se devi annullare le modifiche:

# List available backups
ls -la /opt/n8n/docker-compose.yml.backup_*

# Restore specific backup
cd /opt/n8n
cp docker-compose.yml.backup_20241206_1430 docker-compose.yml
docker compose down && docker compose up -d

Impatto sui costi e sulle prestazioni

Analisi dei costi della memoria

Limiti di payload più elevati influiscono sui costi del server:

Server RAM Requirements:
- 16MB limit (default): 1GB RAM sufficient
- 64MB limit: 2GB RAM recommended  
- 128MB limit: 4GB RAM recommended
- 256MB limit: 8GB RAM recommended
- 512MB limit: 16GB RAM recommended

Hetzner Cloud Costs (legacy plans, deprecated by Hetzner in June 2024; check current pricing):
- CX11 (2GB RAM): €4.51/month
- CX21 (4GB RAM): €8.46/month  
- CX31 (8GB RAM): €16.07/month

Benefici sulle prestazioni

Limiti di payload più elevati offrono vantaggi in questi ambiti:

• Elaborazione dei file: Gestire documenti, immagini e video
• Integrazione dei dati: Elaborare risposte API di grandi dimensioni
• Operazioni in blocco: Trasformare gli insiemi di dati in modo efficiente
• Debug: Testare flussi di lavoro complessi nodo per nodo

Conclusione

Aumentare N8N_PAYLOAD_SIZE_MAX dal valore predefinito di 16MB a un valore adeguato al server abilita potenti funzionalità prima impossibili con le esecuzioni parziali. Il limite di 256MB che abbiamo configurato copre molto bene la maggior parte degli scenari reali, mantenendo la stabilità del server.

Principali vantaggi di questa configurazione

• Produttività: Eseguire il debug di flussi complessi nodo per nodo con molte meno restrizioni di dimensione
• Capacità: Elaborare file e grandi insiemi di dati in modo efficiente
• Convenienza: Usare un limite di 128MB su un server con 4GB di RAM per meno di €10/mese (prezzo del vecchio piano Hetzner CX21 riportato sopra)
• Affidabilità: Configurazione testata in produzione con una gestione adeguata delle risorse
• Scalabilità: Adeguare facilmente i limiti all’aumentare della complessità dei flussi di lavoro

Questa configurazione si basa sulla nostra guida originale alla configurazione di n8n e sulla guida alla risoluzione dei problemi dei webhook per creare una piattaforma di automazione completa e pronta per la produzione, capace di gestire flussi di elaborazione dei dati di livello aziendale.

Per requisiti di payload specializzati o ad alto volume, valuta una consulenza con esperti di automazione per ottimizzare il tuo caso d’uso e garantire un’allocazione ottimale delle risorse del server.

Informazioni su tva

tva assicura la gestione completa delle infrastrutture di sistemi di database, ambienti cloud e supply chain globali. Il nostro approccio metodico combina rigorosi protocolli di sicurezza con l’ottimizzazione delle prestazioni, mentre i servizi di consulenza strategica consentono un coordinamento preciso delle competenze digitali e delle risorse fisiche, mantenendo i più elevati standard di eccellenza operativa e conformità in tutti gli incarichi.

Visita tva.sg per maggiori informazioni sui nostri servizi e su altri tutorial di automazione.