Problème de mémoire insuffisante

Questions
1

Bonjour à la communauté n8n,

Je fais face à un grave problème de manque de mémoire sur mon instance n8n Cloud après la récente mise à jour de sécurité n8n.

Mes workflows fonctionnaient parfaitement jusqu’au 25 juin et tournaient de manière fiable depuis 7 mois. Je n’ai apporté aucune modification aux workflows, nœuds, identifiants, configurations ou variables d’environnement au cours de la semaine passée.

Après la récente mise à jour de version de sécurité n8n, plusieurs workflows de production ont commencé à échouer lors de l’exécution. Lorsque ces workflows s’exécutent, l’instance devient instable ou ne répond plus, les automatisations arrêtent de fonctionner, et l’instance finit par manquer de mémoire.

J’ai déjà essayé de supprimer les exécutions enregistrées, de réduire l’historique d’exécution et de supprimer les nœuds Wait pour réduire l’utilisation de la mémoire, mais le problème persiste. Même après la suppression des exécutions, lorsque les workflows s’exécutent à nouveau, l’instance manque toujours de mémoire ou plante.

Le même problème s'est également produit en mai après une mise à jour de n8n Cloud. À ce moment-là, mes workflows étaient également stables depuis plusieurs mois sans aucune modification de ma part, mais après la mise à jour, l'instance a commencé à planter avec des erreurs de manque de mémoire. Le problème a finalement été résolu après que n8n ait mis à jour l'instance. Maintenant, après la dernière mise à jour, je fais face au même type de problème à nouveau.

Cela a commencé uniquement après la récente mise à jour, je voudrais donc comprendre s’il y a eu des modifications récentes dans n8n Cloud liées à la gestion de la mémoire, au comportement des exécutions, aux exécutions enfants, à la concurrence des workflows ou au comportement des nœuds.

J’apprécierais les conseils de l’équipe n8n ou de la communauté sur la façon de déboguer ceci et d’identifier ce qui cause le pic de mémoire.

J’aimerais également savoir si quelqu’un d’autre fait face au même problème après la récente mise à jour, ou si cela se produit uniquement sur mon instance.

Résultat retourné par le dernier nœud

Les workflows échouent avant de se terminer avec succès. L’état d’exécution indique Error, et le problème principal est le comportement de manque de mémoire au niveau de l’instance.

Dans certains cas, les exécutions échouent très rapidement, par exemple en quelques millisecondes. Dans d’autres cas, elles s’exécutent pendant plusieurs secondes avant d’échouer.

L’instance devient également instable ou ne répond plus lorsque les workflows s’exécutent.

Informations sur ma configuration n8n

Version n8n : dernière version mise à jour de n8n Cloud
Base de données : base de données gérée par n8n Cloud
Paramètre n8n EXECUTIONS_PROCESS : géré par n8n Cloud / non directement configuré par moi
Exécution de n8n via : n8n Cloud
Système d’exploitation : géré par n8n Cloud / non applicable

Notes supplémentaires

Les workflows étaient stables avant la récente mise à jour. Ce problème a commencé après la mise à jour, sans aucune modification de ma part.

J’aimerais savoir :

  1. Y a-t-il eu une récente mise à jour n8n qui a modifié l’utilisation de la mémoire, la gestion des exécutions, la concurrence des workflows ou le comportement des nœuds ?

  2. Existe-t-il un contournement, un correctif, une option de restauration ou un paramètre recommandé pour stabiliser l’instance ?

  3. Puisque le même problème s’est produit en mai après une mise à jour n8n et a été résolu du côté n8n, l’équipe peut-elle vérifier s’il s’agit d’un problème similaire au niveau de l’instance ou lié à la version ?

2

@Asher_TMT quelques personnes ont rencontré le même OOM post-mise à jour sur Cloud, ce qui indique une régression mémoire dans la version vers laquelle tu as été mis à jour automatiquement, rien à voir avec tes changements. Quelle version Cloud a été changée vers/depuis autour du 25, ça permettra de confirmer. Mécaniquement, n8n conserve toutes les données des éléments en mémoire pendant toute l’exécution, donc une build qui en garde plus par élément fait basculer les workflows qui étaient correctement dimensionnés. Puisque nettoyer l’historique sauvegardé n’a pas aidé, ton levier se situe en mémoire pendant l’exécution et non l’historique stocké, supprime les gros champs avec un nœud Set entre les nœuds lourds et divise les étapes les plus lourdes en sous-workflows pour que chacune ait sa propre portée mémoire.

3

Ce schéma mérite qu’on le prenne au sérieux : stable pendant 7 mois, aucune modification de votre côté, dysfonctionnement immédiatement après une mise à jour de la plateforme, et exactement la même chose s’est produite en mai et a été résolue quand n8n a mis à jour votre instance. Cette corrélation pointe bien plus vers une régression au niveau de l’instance/version que vers vos workflows. Quelques réflexions, divisées en « ce que seul n8n peut faire » et « ce que vous pouvez faire pour réduire les possibilités ».

Escaladez directement — c’est le vrai chemin pour la résolution. Puisque vous êtes sur n8n Cloud, les éléments qui résolvent vraiment les problèmes de mémoire au niveau de l’instance (un correctif, une restauration, ou une augmentation de l’instance) dépendent de n8n, pas de vous — exactement comme en mai. Ouvrez un ticket de support et référencez explicitement l’incident de mai (même symptôme, résolu par la mise à jour de l’instance par n8n), plus la date du début (25 juin) et la version avant/après. Cette formulation tend à le router comme une régression plutôt que comme une question de configuration.

En attendant, réduisez le coupable — cela vous permet de continuer à fonctionner et donne au support une solution plus rapide :

  • Trouvez le workflow fautif. Dans Executions, alignez les timestamps des plantages avec le workflow qui était en cours d’exécution. Un pic de mémoire remonte presque toujours à un ou deux workflows, pas à tous.
  • Les coupables habituels de mémoire (une mise à jour peut modifier le comportement des nœuds juste assez pour pousser un workflow précédemment stable au-delà de la limite) : les charges utiles volumineuses maintenues en mémoire (grandes réponses HTTP, fichiers binaires/images/PDF passés par plusieurs nœuds), les boucles / SplitInBatches qui accumulent tous les éléments au lieu de les traiter par chunks, et les exécutions enfants de sous-workflow (« Execute Workflow ») se multipliant sous concurrence.
  • Isolez par désactivation. Désactivez temporairement les workflows les plus lourds / les plus fréquents un à la fois et observez quand l’instance se stabilise — cela identifie rapidement la cause.
  • Un levier que les gens oublient : au-delà de l’historique d’exécution global, vérifiez les paramètres de chaque workflow lourd et réglez « Save execution progress » sur off et « Save successful executions » sur off. L’enregistrement de la progression écrit les données de chaque nœud et représente un vrai coût mémoire pour les workflows à charges utiles volumineuses. Vous avez déjà réduit l’historique global, mais ce paramètre par workflow est distinct.
  • Pour les workflows manipulant de gros volumes de données, paginisez / batchisez afin de ne jamais conserver l’ensemble complet des données en mémoire à la fois, et évitez de passer du contenu binaire par plus de nœuds que nécessaire.

Pour accélérer le ticket, fournissez-leur : la version exacte avant/après, la date de début, la référence au ticket de mai, le workflow spécifique + nœud, quelques ID d’exécution plantée, et si c’est lié à des exécutions concurrentes. C’est généralement suffisant pour qu’ils reproduisent le problème.

Étant donné le précédent de mai, mon analyse honnête est que c’est très probablement quelque chose que n8n doit corriger de son côté — mais les étapes ci-dessus devraient vous maintenir stable et accélérer la correction de toute façon.

4

L’angle de la régression mémoire semble plausible, surtout si rien n’a changé dans vos workflows et que les défaillances ont commencé immédiatement après la mise à jour Cloud. Le chemin technique immédiat consiste à réduire la mémoire en exécution : supprimer les champs volumineux au plus tôt, diviser les branches lourdes en sous-workflows, éviter de transporter des payloads complets dans les nœuds ultérieurs, et isoler le workflow qui provoque d’abord un pic mémoire.

Pour les workflows de production, je traiterais également ceci comme un incident, pas seulement comme une tâche de débogage :

  1. Lister les workflows défaillants et les clients/processus qu’ils affectent.
  2. Enregistrer le moment où le problème a commencé et quelle version n8n a changé.
  3. Ajouter une vérification temporaire qui confirme que les workflows critiques se terminent.
  4. Documenter l’atténuation que vous avez appliquée, comme la suppression de champs ou la division en sous-workflows.
  5. Décider si le client/stakeholder a besoin d’une mise à jour de statut.

Le risque opérationnel est que plusieurs workflows échouent silencieusement pendant que tout le monde se concentre sur la cause racine. Conservez un court journal des problèmes jusqu’à ce que la plateforme soit stable à nouveau.