Problema de memória insuficiente

Perguntas
1

Olá comunidade n8n,

Estou enfrentando um sério problema de falta de memória na minha instância n8n Cloud após a recente atualização de segurança do n8n.

Meus workflows funcionavam perfeitamente até 25 de junho e vinham sendo executados de forma confiável nos últimos 7 meses. Não fiz nenhuma alteração em workflows, nós, credenciais, configurações ou variáveis de ambiente durante a semana passada.

Após a recente atualização de versão de segurança do n8n, múltiplos workflows de produção começaram a falhar durante a execução. Quando esses workflows são executados, a instância fica instável ou sem resposta, as automações param de ser executadas e a instância eventualmente fica sem memória.

Já tentei deletar execuções salvas, reduzir o histórico de execução e remover nós Wait para reduzir o uso de memória, mas o problema continua. Mesmo após deletar as execuções, quando os workflows são executados novamente, a instância ainda fica sem memória ou trava.

O mesmo problema também aconteceu em maio após uma atualização do n8n Cloud. Naquela época, meus workflows também estavam estáveis há vários meses sem nenhuma mudança da minha parte, mas após a atualização a instância começou a travar com erros de falta de memória. O problema foi eventualmente resolvido após o n8n atualizar a instância. Agora, após a última atualização, estou enfrentando o mesmo tipo de problema novamente.

Isso começou apenas após a atualização recente, então gostaria de entender se houve alguma mudança recente no n8n Cloud relacionada ao gerenciamento de memória, comportamento de execução, execuções filhas, concorrência de workflows ou comportamento de nós.

Agradecerei orientação do time n8n ou da comunidade sobre como debugar isso e identificar o que está causando o pico de memória.

Também gostaria de saber se mais alguém está enfrentando o mesmo problema após a atualização recente, ou se isso está acontecendo apenas na minha instância.

Saída retornada pelo último nó

Os workflows falham antes de completar com sucesso. O status de execução mostra Erro, e o principal problema é o comportamento de falta de memória no nível da instância.

Em alguns casos, as execuções falham muito rapidamente, por exemplo em milissegundos. Em outros casos, elas são executadas por vários segundos antes de falhar.

A instância também fica instável ou sem resposta quando os workflows são executados.

Informações sobre minha configuração n8n

Versão n8n: versão mais recente atualizada do n8n Cloud
Banco de dados: banco de dados gerenciado do n8n Cloud
Configuração n8n EXECUTIONS_PROCESS: gerenciada pelo n8n Cloud / não configurada diretamente por mim
Executando n8n via: n8n Cloud
Sistema operacional: gerenciado pelo n8n Cloud / não aplicável

Notas adicionais

Os workflows estavam estáveis antes da atualização recente. Este problema começou após a atualização, sem nenhuma alteração da minha parte.

Gostaria de saber:

  1. Houve alguma atualização recente do n8n que mudou o uso de memória, tratamento de execução, concorrência de workflows ou comportamento de nós?

  2. Existe alguma solução alternativa, patch, opção de rollback ou configuração recomendada para estabilizar a instância?

  3. Como o mesmo problema aconteceu em maio após uma atualização do n8n e foi resolvido pelo lado do n8n, o time pode verificar se este é um problema semelhante no nível da instância ou relacionado à versão?

2

@Asher_TMT algumas pessoas enfrentaram esse mesmo problema de OOM pós-atualização no Cloud, então aponta para uma regressão de memória na versão para a qual você foi auto-atualizado, não em nada que você tenha mudado. qual versão o Cloud moveu você de e para por volta do 25º, isso determina. em termos de mecanismo, o n8n mantém todos os dados dos itens na memória durante toda a execução, então uma build que carrega mais por item derruba workflows que estavam bem dimensionados. já que limpar o histórico salvo não ajudou, seu recurso está na memória em execução, não no histórico armazenado — remova campos grandes com um nó Set entre os nós pesados e divida os passos mais pesados em sub-workflows para que cada um tenha seu próprio escopo de memória.

3

Esse padrão merece atenção: estável por 7 meses, nenhuma mudança de seu lado, quebra logo após uma atualização da plataforma, e exatamente a mesma coisa aconteceu em maio e foi resolvida quando a n8n atualizou sua instância. Essa correlação aponta muito mais para uma regressão no nível da instância/versão do que para seus workflows. Algumas ideias, divididas em “o que apenas a n8n pode fazer” e “o que você pode fazer para estreitar a busca”.

Escale o problema diretamente — esse é o caminho real para uma solução. Como você está na n8n Cloud, as coisas que realmente resolvem memória no nível da instância (um patch, um rollback ou atualizar a instância) estão do lado da n8n, não do seu — exatamente como em maio. Abra um ticket de suporte e referencie explicitamente o incidente de maio (mesmo sintoma, resolvido pela n8n atualizando a instância), mais a data em que começou (25 de junho) e a versão antes/depois. Esse enquadramento tende a rotear como uma regressão em vez de uma questão de configuração.

Enquanto isso, estreite a busca pelo culpado — isso mantém você funcionando e dá ao suporte uma solução mais rápida:

  • Encontre o workflow ofensor. Em Executions, alinhe os timestamps de crash com qual workflow estava em execução. Um pico de memória quase sempre se rastreia de volta a um ou dois workflows, não a todos.
  • Culpados usuais de memória (uma atualização pode mudar o comportamento do nó o suficiente para empurrar um workflow antes estável para além do limite): payloads grandes mantidos em memória (grandes respostas HTTP, arquivos binários/imagens/PDFs passados por muitos nós), loops / SplitInBatches que acumulam todos os itens em vez de processar em chunks, e execuções de sub-workflow (“Execute Workflow”) filhas se multiplicando sob concorrência.
  • Isole por desativação. Desative temporariamente os workflows mais pesados / mais frequentes um de cada vez e observe quando a instância fica estável — isso localiza a causa rapidamente.
  • Uma alavanca que as pessoas perdem: além do histórico de execução global, verifique as configurações de cada workflow pesado e defina “Save execution progress” como desativado e “Save successful executions” como desativado. Salvar progresso escreve dados de cada nó e é um custo real de memória em workflows com payloads grandes. Você já cortou o histórico global, mas essa configuração por workflow é separada.
  • Para workflows com grandes volumes de dados, pagine / faça lotes para nunca manter o dataset completo na memória de uma vez, e evite passar dados binários por mais nós do que o necessário.

Para agilizar o ticket, forneça a eles: a versão exata antes/depois, a data de início, a referência do ticket de maio, o workflow específico + nó, alguns IDs de execução com crash, e se está vinculado a execuções concorrentes. Isso geralmente é suficiente para que eles reproduzam.

Dado o precedente de maio, minha leitura honesta é que isso provavelmente é algo que a n8n precisa corrigir de seu lado — mas as etapas acima devem mantê-lo estável e acelerar a solução de qualquer forma.

4

O aspecto de regressão de memória parece plausível, especialmente se nada mudou em seus fluxos de trabalho e as falhas começaram logo após a atualização da Cloud. O caminho técnico imediato é reduzir a memória em execução: descartar campos grandes o mais cedo possível, dividir branches pesadas em sub-fluxos de trabalho, evitar carregar payloads completos através de nós posteriores e isolar o fluxo de trabalho que causa pico de memória primeiro.

Para fluxos de trabalho em produção, eu também trataria isso como um incidente, não apenas como uma tarefa de depuração:

  1. Liste quais fluxos de trabalho estão falhando e quais clientes/processos são afetados.
  2. Registre quando o problema começou e qual versão do n8n mudou.
  3. Adicione uma verificação temporária que confirme se os fluxos de trabalho críticos estão sendo concluídos.
  4. Documente a mitigação que você aplicou, como remoção de campos ou divisão de sub-fluxos de trabalho.
  5. Decida se o cliente/stakeholder precisa de uma atualização de status.

O risco operacional é que múltiplos fluxos de trabalho falhem silenciosamente enquanto todos se concentram na causa raiz. Mantenha um registro de problemas breve até que a plataforma esteja estável novamente.