Problèmes critiques "n8n may have run out of memory" depuis cette semaine

Questions
1

Décrivez le problème/erreur/question

À partir de cette semaine, nous rencontrons un problème critique de mémoire. Nous avons une automatisation qui s’exécute une fois par jour depuis environ 3 mois et qui parcourt les contacts dans notre CRM pour envoyer un appel d’agent IA via Telnyx pour les appels de suivi. Tout fonctionnait correctement jusqu’à cette semaine, où nous avons commencé à recevoir l’erreur : « L’exécution s’est arrêtée à ce nœud - n8n n’a peut-être pas eu suffisamment de mémoire pour exécuter cette exécution. »

Pire encore, en essayant de consulter l’historique d’exécution, les données d’exécution ne sont pas visibles ou sauvegardées. Les nœuds qui se sont déjà exécutés affichent simplement : « Impossible d’afficher les données. L’exécution a été interrompue, donc les données n’ont pas été sauvegardées. Essayez de corriger le workflow et de le réexécuter. »

image
image2517×1226 90.4 KB

Pour cette raison, nous ne pouvons pas effectuer de récupération manuelle de données ou de continuation du workflow. Cela a causé des problèmes importants cette semaine, et nous avons dû réconcilier nos registres et rattraper les workflows d’appels qui auraient pu échouer à mi-parcours.

Mercredi dernier et hier, il s’est exécuté sans aucun problème. Mais quand c’est le cas, il s’arrête et l’erreur se produit sur un nœud aléatoire. Il n’y a eu aucun changement à notre workflow ou à notre instance n8n depuis le lancement de cette automatisation, à l’exception des mises à jour fréquentes de l’instance n8n. Il n’y a pas d’autres automatisations en cours d’exécution sur notre instance.

Y a-t-il eu un changement récent dans les limites d’abonnement au cloud n8n ou dans l’utilisation/allocation de la mémoire ? Cela a été tout un défi cette semaine.

Merci.

Quel est le message d’erreur (le cas échéant) ?

image
image2511×1217 157 KB

L’exécution s’est arrêtée à ce nœud
n8n n’a peut-être pas eu suffisamment de mémoire pour exécuter cette exécution. Plus de contexte et de conseils sur comment éviter cela

Veuillez partager votre workflow

Ce projet implique plusieurs workflows et sous-workflows. Bien que nous souhaitions fournir autant de contexte que possible, nous ne pouvons pas partager les fichiers publiquement car ils contiennent nos connexions internes à l’entreprise et nos détails de configuration. Nous serions heureux de les fournir via un e-mail d’assistance si possible.

Voici un exemple d’un workflow qui a échoué.

image
image1920×1020 293 KB

Partagez le résultat retourné par le dernier nœud

Le dernier nœud n’a aucun résultat et affiche uniquement la bannière d’erreur « L’exécution s’est arrêtée à ce nœud ».

Informations sur votre configuration n8n

  • Version de n8n : 2.21.3
  • Base de données (par défaut : SQLite) : sqlite
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : n8n Cloud
  • Système d’exploitation : Windows 11 Pro
3

Pouvez-vous revenir à la version précédente fonctionnelle de n8n ?

4

Salut, je ne pense pas que je puisse rétrograder la version via le tableau de bord n8n - je peux seulement basculer entre la dernière version bêta ou stable.

image
image1235×444 29.4 KB

5

Je suis confronté au même problème après avoir mis à jour N8N cette semaine. La même erreur « manque de mémoire » se produit. Les workflows fonctionnaient correctement depuis les 6 derniers mois, mais maintenant tous les workflows sont désactivés à cause de ce problème.

J’ai également réduit la charge, mais le même problème persiste. Auparavant, je traitais des charges de travail beaucoup plus importantes, et N8N ne s’arrêtait jamais en panne. Maintenant, même en traitant seulement environ 60% de cette charge précédente, il plante toujours.

6

Salut, je connais ce problème – c’est un dépassement classique de limite mémoire dû à une charge d’éléments incontrôlée sur n8n Cloud.

La cause provient de la façon dont ton workflow traite les contacts du CRM. C’est solvable, mais la bonne stratégie de correction dépend de la structure actuelle de ta boucle et du nombre de contacts en cours simultanément.

Deux questions :

  • Combien de contacts traverse le workflow chaque jour environ ?

  • Utilises-tu un nœud Split-in-Batches ou tout s’exécute en une seule passe ?

Après ça je pourrai te dire exactement ce qui faut modifier.

7

Le timing (commencé cette semaine après un fonctionnement normal pendant des mois) combiné au fait que plusieurs personnes le voient suggère une régression dans une récente mise à jour de n8n. Deux choses à vérifier dès maintenant :

  1. Vérifiez votre version de n8n par rapport au journal des modifications - si vous utilisez n8n Cloud, elle a peut-être été mise à jour automatiquement. Recherchez les modifications liées à la gestion des données d’exécution ou à la gestion de la mémoire des nœuds IA autour de la version que vous avez actuellement.

  2. Pour le workflow lui-même : l’appel de l’agent IA parcourant les contacts du CRM est le point d’augmentation de mémoire probable - chaque tour d’agent conserve le contexte d’exécution en mémoire jusqu’à la fin de l’exécution. Si la taille du batch n’est pas contrôlée (par exemple, tous les contacts s’exécutant en parallèle via un nœud Loop sans Split in Batches), une mise à jour de n8n qui a changé la façon dont les snapshots d’exécution sont stockés pourrait causer un pic soudain. Essayez d’envelopper l’appel de l’agent IA dans un nœud Split in Batches avec une taille de batch de 10-20 et voyez si la mémoire se stabilise.

8

@glenbenatiro, bonjour!
ce n’est pas possible d’affirmer que c’est un bug, commencez d’abord par comparer si tous les volumes sont identiques entre ce qui fonctionnait avant et maintenant (ex: nombre de contacts traités, taille des payloads) et je désactiverais la sauvegarde des exécutions réussies en production.