Buscar K
Aparência
Requisitos de Hardware do Agente
O Agente do HorusETL roda na sua infraestrutura e é leve por natureza. Ainda assim, o consumo de recursos varia conforme o tipo de fluxo, o paralelismo e o volume de dados. Esta página dá um número recomendado direto para repassar à sua equipe de TI e, logo abaixo, explica as nuances para quem precisa dimensionar com mais precisão.
TIP
Não sabe por onde começar? Use o perfil Recomendado abaixo (2 vCPU / 4 GB RAM). Atende a grande maioria dos cenários. Se for rodar transformações Python/pandas pesadas, comece direto no perfil de Alto Desempenho.
📐 Perfis Recomendados
| Perfil | vCPU | RAM | Disco livre | Quando usar |
|---|---|---|---|---|
| Mínimo (piso) | 1 | 2 GB | 10 GB | Baixo volume, sem paralelismo, fluxos apenas de banco → Data Warehouse. Roda, mas sem folga. |
| Recomendado ✅ | 2 | 4 GB | 10 GB | Uso geral: paralelismo de 2 a 4 fluxos, mix de fontes, volumes moderados. É este o número padrão. |
| Alto Desempenho | 4+ | 8 GB+ | 20 GB | Python/pandas pesado, alto paralelismo (8+ fluxos simultâneos) ou grandes volumes carregados em memória. |
Esses valores valem tanto para Windows quanto para Linux (Docker). Veja também os pré-requisitos de sistema operacional e runtime.
🤔 Por que "depende"?
O agente não tem um consumo fixo como o de um banco de dados. O que ele usa varia conforme o que você roda. Dois fatores definem o tamanho da máquina.
1. Tipo de fluxo: streaming x carga em memória
- Banco → Data Warehouse (ODBC, SQL Server, Oracle, etc.): é streamado. O agente lê em lotes pequenos (cerca de 5.000 linhas por vez) e grava direto, mantendo o uso de memória praticamente constante, independente do tamanho da tabela. Uma tabela de 10 mil ou de 10 milhões de linhas consome quase a mesma RAM. É o cenário mais leve.
- Python / pandas: cada execução de um nó Python sobe um processo separado. Se o script carrega os dados inteiros em memória (por exemplo,
pd.concatoumergede DataFrames grandes), o consumo sobe rápido, de centenas de MB a vários GB por execução. É o cenário mais pesado.
2. Paralelismo e tenants
Cada agendamento que roda ao mesmo tempo é um processo independente, então RAM e CPU somam. Mas o que pode rodar em paralelo depende dos tenants, e não só do número configurado em Agendamentos Simultâneos:
- Agendamentos do mesmo tenant nunca rodam em paralelo. Eles são serializados, executados um de cada vez, em fila. Isso é proposital: protege o banco de origem e o Data Warehouse daquele cliente contra várias extrações simultâneas.
- O paralelismo ocorre entre tenants diferentes. Em um agente compartilhado (whitelabel, atendendo vários tenants), o limite de Agendamentos Simultâneos define quantos tenants distintos podem rodar ao mesmo tempo.
IMPORTANT
Consequência prática para o dimensionamento:
- Agente de um cliente só (um tenant): a concorrência real é de cerca de 1 agendamento por vez, independente do valor de Agendamentos Simultâneos. A RAM é ditada pelo fluxo mais pesado, e não pela multiplicação por paralelismo.
- Agente compartilhado (whitelabel, vários tenants): a concorrência real é o número de tenants rodando juntos no pico (até o teto configurado). É aqui que a RAM cresce de forma aproximadamente linear. Dimensione por quantos tenants disparam ao mesmo tempo.
O paralelismo é configurado por agente (veja Gerenciamento de Agentes).
NOTE
CPU raramente é o gargalo. Na prática, o consumo de CPU dos agentes fica baixo na média e atinge picos de cerca de 1,5 núcleo mesmo sob carga e paralelismo. O fator que mais determina o tamanho da máquina é a memória RAM.
🔁 Fila, Paralelismo e Encavalamento
O agente nunca estoura o limite de paralelismo configurado. Mesmo que centenas de agendamentos sejam disparados de uma vez, ele executa no máximo o teto definido e enfileira o restante, processando conforme os slots liberam. Isso protege a máquina de sobrecarga e mantém o uso de RAM com um teto previsível.
A regra-chave, como visto acima: agendamentos do mesmo tenant são serializados (1 por vez) e o paralelismo só atua entre tenants diferentes.
⚠️ O risco de encavalamento (backlog)
O ponto de atenção é o acúmulo de fila. Se o tempo total de execução dos agendamentos de um tenant em um período for maior que o intervalo de agendamento, a fila cresce e as execuções vão atrasando progressivamente.
Exemplo: um cliente (tenant) com 10 agendamentos a cada 10 minutos, cada um levando mais de 1 minuto.
- Como são do mesmo tenant, rodam um de cada vez: 10 × (>1 min) dá mais de 10 minutos para drenar. No intervalo seguinte eles já dispararam de novo, então a fila nunca esvazia e o atraso só cresce. Esse é o encavalamento.
- Aumentar o paralelismo NÃO resolve esse caso, porque agendamentos do mesmo tenant não rodam em paralelo de qualquer forma.
Como resolver o encavalamento
A solução depende do cenário:
| Cenário | Como resolver |
|---|---|
| Um cliente (tenant) com agendamentos se acumulando | Espace os agendamentos (intervalo maior), reduza o tempo de cada fluxo (filtros, cargas incrementais) ou agrupe fluxos em um único agendamento. Aumentar o paralelismo não ajuda, porque eles serializam. |
| Agente compartilhado (whitelabel) com muitos tenants | Aumente o paralelismo para permitir mais tenants simultâneos e aumente a RAM proporcionalmente (o consumo cresce de forma aproximadamente linear com o nº de tenants rodando juntos). |
TIP
Regra prática: garanta que o tempo total de execução dos agendamentos de um tenant caiba dentro do intervalo de agendamento. Em agente de cliente único, isso se resolve no desenho dos fluxos e no espaçamento. Em agente whitelabel, também subindo o paralelismo (e a RAM).
📊 O que observamos na prática
Medições reais de agentes em produção, ao longo de 30 dias, mostram o seguinte padrão:
| Cenário | RAM típica (média) | RAM em pico (p95) | CPU em pico |
|---|---|---|---|
| Agente de cliente único (um tenant) | ~1,3 GB | ~1,7 GB | ~1,5 núcleo |
| Agente compartilhado (vários tenants) | ~1,2 GB | ~3 GB | ~1,5 núcleo |
| Agente com Python/pandas pesado | ~2,6 GB | ~4 GB (picos pontuais bem acima) | ~1,5 núcleo |
TIP
Um agente "típico" cabe confortavelmente em 4 GB. Já cargas Python pesadas podem ultrapassar 8 GB em execuções específicas. Nesses casos, aumente a RAM (em agente whitelabel, reduzir o paralelismo também ajuda a limitar quantos tenants rodam juntos).
💾 Disco e Rede
- Disco: reserve espaço para a imagem do agente e para os arquivos temporários (Parquet) gerados durante as execuções. Esses temporários são limpos automaticamente, mas existe um pico de uso durante fluxos grandes. 10 GB livres é um piso seguro; 20 GB para cargas pesadas.
- Rede: apenas conectividade de saída HTTPS (porta 443) para a plataforma. O agente é firewall-friendly e não precisa de portas abertas para entrada. Detalhes em Comunicação e Redes.
✅ Resumo
- Não sabe dimensionar? Vá de 2 vCPU / 4 GB RAM, que cobre a maioria dos casos.
- Só fluxos de banco → DW, volume baixo, sem paralelismo? 1 vCPU / 2 GB RAM já roda.
- Python/pandas pesado ou agente whitelabel com muitos tenants? 4+ vCPU / 8 GB+ RAM.
- CPU dificilmente é o limite, então dimensione pela RAM. Lembre que agendamentos do mesmo tenant serializam, e o consumo somado de RAM só cresce com o nº de tenants rodando juntos.