Temos muitos desenvolvedores novos no nosso servidor n8n. Com o aumento de usuários e consultas de dados maiores, estou procurando melhorias de escala. Atualmente estou executando n8n no Windows via node com um banco de dados PostgreSQL no mesmo servidor.
Quero migrar para dockers e modo de fila para que eu possa aumentar a contagem de workers.
Isso ajudará a reduzir o impacto de um workflow com grande volume de dados, permitindo que os outros workers continuem enquanto um fica travado? Atualmente, o servidor inteiro sofre atrasos ou teremos um javascript heap out of memory.
No momento, seu setup n8n é como uma loja de uma pessoa só onde a mesma pessoa atende o telefone, anota o pedido e cozinha a comida. Se um pedido massivo e complicado chegar, essa pessoa fica sobrecarregada, o telefone para de ser atendido, e toda a loja fica paralisada até que o pedido seja finalizado ou a pessoa desabe de cansaço.
Mudar para “Queue Mode” é como contratar um gerente e um time de chefs. O gerente (o Main process) só cuida do telefone e do agendamento, enquanto os chefs (os Workers) fazem a cozinha de verdade lá atrás. Isso significa que mesmo que um chef esteja lutando com um pedido gigante, o gerente ainda pode conversar com clientes, e os outros chefs conseguem continuar preparando pedidos menores sem nenhum atraso.
Isso também resolve seus crashes de memória. Em vez de um balde gigante de memória que todos compartilham, cada chef ganha seu próprio espaço de trabalho dedicado. Se um workflow específico é tão grande que faz um worker crashear, ele só mata aquele “chef”. O resto do sistema continua online, e o worker que caiu pode ser automaticamente reiniciado sem afetar nenhum outro usuário.
Em resumo, enquanto esse setup é um pouco mais complexo de montar porque você precisa adicionar uma ferramenta chamada Redis para coordenar o trabalho, é a única maneira de suportar um time crescente. Ele transforma seu servidor de um ponto único de falha frágil em um sistema profissional que consegue crescer conforme seus dados e contagem de usuários aumentam.
Com o modo de fila você realmente tem mais opções para distribuir a carga, então consegue resolver isso com ele. Pode não ser tão simples quanto apenas ativá-lo também, porque você mencionou problemas de memória.
Sim, o modo de fila ajudará com seu problema específico, que é um fluxo de trabalho pesado bloqueando tudo mais para seus outros desenvolvedores. A analogia do restaurante acima está correta: agora uma única consulta de dados grande ocupa o único processo e todos os outros esperam. O modo de fila permite adicionar workers para que um trabalho pesado ocupe um worker enquanto os outros continuam atendendo.
Alguns detalhes específicos para sua configuração. Sair do Windows-node para Docker vale a pena por si só, o caminho Docker é o suportado e previsível, e o modo de fila é muito mais fácil de executar lá. Mantenha o Postgres, mas considere movê-lo para fora do mesmo servidor que n8n uma vez que você dimensiona os workers, porque se o banco de dados e os workers competem pelo mesmo CPU e memória, você apenas move o gargalo. Comece com dois ou três workers e monitore o uso de recursos em vez de provisionamento em excesso.
Uma coisa que o modo de fila não corrige: um único fluxo de trabalho que puxa um conjunto de dados enorme na memória em uma única execução ainda sobrecarregará um worker. Então, junto com a mudança, verifique se esse fluxo de trabalho de grandes dados pode processar em lotes ou empurre a consulta pesada para o Postgres em vez de carregar tudo no n8n. O modo de fila impede que bloqueie os outros, o agrupamento em lotes impede que sobrecarregue o worker em que cai. O que o fluxo de trabalho pesado realmente faz, uma consulta grande seguida de processamento ou manipulação de arquivos grandes?
Parece que estou no caminho certo para escalar nosso ambiente.
Não estou trabalhando diretamente com todos os nossos devs nem envolvido nos dados que estão enviando pelo n8n. Estive monitorando os logs do n8n esperando ver algo que me mostre quais workflows estão usando mais recursos e causando a ocupação (desconexão), mas ainda não encontrei.
Parece que posso ter meu ambiente docker pronto para iniciar essa migração semana que vem. desejam-me sorte!
Boa sorte @jbenway
caso tenha encontrado a sua solução por aqui, por favor marque a melhor resposta como solução para apoiar a comunidade. best regards
Lendo sua descrição, estou basicamente na mesma situação que você: um número crescente de desenvolvedores e fluxos de trabalho, além de alguns trabalhos “pesados” que podem exercer pressão perceptível em uma única instância do n8n. Também estou executando o n8n em uma única máquina (com Postgres na mesma caixa), e vi como um grande fluxo de trabalho de dados pode desacelerar tudo ou até disparar um erro de heap de JavaScript insuficiente quando tenta fazer muito de uma vez.
Pela minha compreensão e experimentos até agora, migrar para Docker + modo de fila realmente ajuda com exatamente a preocupação que você mencionou:
O processo main se concentra em webhooks, triggers e agendamento.
Um ou mais workers fazem a execução real em processos Node.js separados.
Portanto, se um fluxo de trabalho pesado se comportar mal em um worker, isso afeta principalmente esse worker, enquanto a instância principal e os outros workers podem continuar rodando. Isso já é uma melhoria significativa comparado a um único processo onde UI, triggers e execução vivem todos juntos.
Dito isso, eu não trataria isso como uma solução mágica. O modo de fila não corrigirá automaticamente fluxos de trabalho que tentam carregar ou processar enormes volumes de dados em uma única execução. Você ainda precisa considerar:
Quanta quantidade de dados uma única execução mantém na memória.
Se você pode processar em lotes ou fazer streaming em vez de fazer tudo de uma vez.
Concorrência razoável por worker para que você não sobrecarregue seu banco de dados ou sistemas externos.
Meu próprio plano é:
Migrar para Docker com 1 main + alguns workers no mesmo servidor para obter isolamento e limites claros de CPU/memória por processo.
Começar a usar modo de fila para que execuções pesadas sejam enviadas para workers em vez de bloquear a instância principal.
Ajustar gradualmente o design do fluxo de trabalho e a concorrência assim que eu vir como a nova configuração se comporta sob carga real.
Então, em resumo: sim, Docker + modo de fila deve reduzir o impacto de um único fluxo de trabalho grande e tornar o sistema muito mais estável, desde que você também aproveite a oportunidade para repensar como os fluxos de trabalho mais pesados lidam com dados.