Quando o n8n fica sem memória, ou o sistema mata o contentor (e, com o reinício automático, o Docker volta a levantá-lo sem aviso) ou o fluxo falha com um erro de memória. Quase sempre a causa é a mesma: um fluxo carrega dados a mais de uma só vez. Menos vezes, é o histórico de execuções a crescer, ou um VPS pequeno para tudo o que lá corre.
Confirmar que é memória
| 1 |
Veja o consumo ao vivo com docker stats, enquanto o fluxo suspeito corre. Se a memória do contentor sobe até ao fim e ele cai, é isto.
|
|
| 2 |
Veja a memória do VPS inteiro com free -h. Pode ser outro contentor a consumir, e não o n8n.
|
|
| 3 |
Pergunte ao Docker se foi morto por falta de memória: docker inspect do contentor mostra um campo «OOMKilled» no estado.
|
|
| 4 |
Veja os registos com docker compose logs no momento da queda, e a hora a que o contentor reiniciou, para saber que fluxo estava a correr.
|
|
As causas, e o que fazer a cada uma
| Causa |
O que fazer |
| Um nó lê milhares de linhas de uma vez (base de dados, folha de cálculo, API) |
Peça só as colunas e as linhas de que precisa e processe em lotes, com o nó próprio para isso, descrito na documentação. |
| Ficheiros grandes ou imagens a passar pelo fluxo |
Os dados binários ocupam memória. A documentação do n8n descreve como os guardar em disco em vez de memória; procure as variáveis dos dados binários. |
| Um fluxo chama outro e devolve-lhe tudo |
Parta o trabalho em sub-fluxos que devolvam só o que o seguinte precisa. |
| Muitas execuções ao mesmo tempo |
Espalhe os horários dos agendamentos. Para cargas grandes, a documentação descreve um modo com filas e trabalhadores separados. |
| Histórico de execuções enorme |
Ligue a limpeza automática das execuções antigas (variáveis descritas na documentação) e escolha, nas definições do fluxo, o que vale a pena guardar. Os fluxos muito frequentes enchem o histórico depressa. |
| O nó de código a trabalhar com tudo em memória |
Faça o filtro antes de chegar ao nó, e devolva só o necessário. |
| VPS pequeno, com outros contentores a ajudar |
Some o que cada serviço usa. Se não cabe, o problema é o plano, não o n8n. |
|
Subir o limite de memória do Node não cria memória. O n8n é uma aplicação Node.js e há uma opção para lhe dar mais espaço de trabalho, mas se a máquina não tem a memória, só adia a queda e arrisca-se a que o sistema mate outros serviços. Corrija o fluxo primeiro.
|
Quando é mesmo o plano
Se os fluxos já estão em lotes e a memória continua curta, é a altura de mudar de plano. Compare em Servidores VPS e em Servidores Cloud. Antes, uma olhada ao disco e às outras causas comuns de quedas em erros comuns em VPS e Cloud, e ao espaço que o Docker ocupa em Docker a encher o disco.
Mude uma coisa de cada vez e meça outra vez com docker stats. Assim sabe qual das mudanças resolveu, e não fica com cinco alterações que ninguém lembra.
|
PRODUTO RECOMENDADO Alojamento de sites com cPanel Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 5.940,00 Kz/mês (plano de 3 anos, com cupão) Ver planos |
Português
English
