Como dimensionar um servidor para ERP (Protheus, Sankhya) e RDP com N usuários

Método prático para dimensionar CPU, memória e disco de um servidor para ERP como Protheus e Sankhya e para RDP com N usuários, com exemplo de cálculo.

Para que serve este guia

"Quantos núcleos e quanta memória eu preciso para 30 usuários?" é uma das perguntas mais comuns de quem leva o ERP e o acesso remoto para um servidor dedicado. Não existe resposta única, mas existe um método. Este guia mostra como dimensionar um servidor para ERP (Protheus, Sankhya, Senior, sistemas próprios) e para RDP com N usuários, quais números de referência os fabricantes publicam e um exemplo de cálculo completo.

Etapa 1: separe o ambiente em funções

Um ambiente típico de ERP tem três papéis, e cada um consome recursos de forma diferente:

• Banco de dados (SQL Server, Oracle, PostgreSQL): é o mais sensível a memória e latência de disco. Quanto mais da base couber em RAM, menos o disco é acionado.
• Servidor de aplicação (no Protheus, AppServer e DBAccess; no Sankhya, o servidor Java/WildFly): consome principalmente CPU e memória, proporcionalmente aos usuários e às rotinas em execução.
• Servidor de sessões RDP (Remote Desktop Session Host): onde os usuários abrem o cliente do ERP, o navegador, o Office e o e-mail. Consome CPU e memória por usuário.

Em um servidor dedicado com hypervisor (por exemplo, Proxmox VE), cada papel vira uma ou mais VMs. Isso facilita medir, ajustar e fazer backup de cada parte separadamente. Veja também o artigo sobre virtualização e hypervisor.

Etapa 2: conte usuários simultâneos, não cadastrados

Dimensionamento é feito pelo pico de usuários simultâneos. Uma empresa com 80 usuários cadastrados pode ter 35 conectados no horário de pico. Levante também:

• Horários de pico de login (início do expediente), que pesam muito em servidores RDP.
• Rotinas pesadas: fechamento fiscal e contábil, MRP, relatórios gerenciais, integrações e jobs noturnos.
• Tamanho atual do banco de dados e crescimento anual.
• O que mais roda nas sessões RDP: Office, navegador, PDF, e-mail.

Etapa 3: meça o ambiente atual

Se o ERP já roda em outro lugar, a melhor referência é ele mesmo. Colete dados por pelo menos uma semana, incluindo um fechamento de mês:

• Windows (Monitor de Desempenho): Processor(_Total)\% Processor Time, Memory\Available MBytes, PhysicalDisk\Avg. Disk sec/Read e sec/Write, PhysicalDisk\Disk Transfers/sec e, no RDP, User Input Delay per Session.
• SQL Server: Page life expectancy e o tamanho dos arquivos de dados.
• Linux: sar, iostat -x e vmstat (pacote sysstat).

Latência de disco consistentemente acima de 10 a 20 ms ou memória disponível perto de zero indicam gargalos que o novo servidor precisa resolver.

Como dimensionar o servidor para ERP: referências dos fabricantes

Protheus (TOTVS)

O guia de instalação do Protheus 12 publicado no TDN lista requisitos mínimos para AppServer e SGBD e orienta que ambientes com mais de 50 usuários ou base acima de 5 GB tenham o dimensionamento validado com a TOTVS. Em ambientes maiores, a prática comum é distribuir a carga entre vários serviços AppServer (balanceamento) e manter o banco de dados em VM própria. Alguns módulos, como Call Center e Front Loja, têm acréscimos de memória por usuário indicados na documentação.

Sankhya

A Sankhya publica tabelas de requisitos por faixa de estações. Como ordem de grandeza, uma versão dessa tabela para o servidor de banco de dados ia de 4 vCPUs e 6 GB de RAM para até 5 estações a cerca de 10 vCPUs e 32 GB de RAM acima de 20 estações, com SSD para a base. Confirme a tabela atual com a Sankhya ou com o seu canal de implantação.

Banco de dados em geral

• Dê ao SGBD memória suficiente para manter a parte mais usada da base em cache e limite o consumo (no SQL Server, max server memory) para sobrar memória para o sistema operacional.
• Coloque dados e logs em NVMe. Veja o artigo sobre NVMe, SSD SATA e HDD.
• Lembre do licenciamento: SQL Server Standard e Enterprise são licenciados por núcleo (ou servidor + CAL na Standard), então vCPUs a mais também custam licença.

Como dimensionar um servidor RDP com N usuários

A Microsoft publica uma referência de densidade de usuários por vCPU para hosts de sessão multiusuário:

Outras orientações da mesma documentação:

• Mínimo recomendado de 8 vCPUs e 16 GB de RAM para um host multiusuário.
• Prefira VMs entre 4 e 24 vCPUs. Acima de cerca de 20 usuários por VM, várias VMs menores tendem a funcionar melhor do que uma grande.
• Considere de 15% a 20% de capacidade a menos ao virtualizar, em comparação com hardware físico.
• O login é a operação mais pesada: muitos usuários entrando ao mesmo tempo exigem folga de CPU.

Para memória, a Microsoft não fixa um valor por usuário. Uma estimativa prática usada no mercado é de 2 a 4 GB por usuário em uso de escritório com ERP, somados a cerca de 4 GB para o sistema, ajustando depois pela medição real. Navegadores com muitas abas e sistemas web pesados empurram esse número para cima.

Exemplo de cálculo: ERP + RDP para 30 usuários

Cenário: 30 usuários simultâneos no pico, perfil médio (cliente do ERP, Excel, navegador), banco SQL Server com 60 GB.

1. RDP – CPU: 30 ÷ 4 = 7,5 vCPUs. Seguindo a recomendação de VMs menores e somando folga para login e virtualização, duas VMs de 8 vCPUs com 15 usuários cada.
2. RDP – memória: 15 usuários × 2,5 GB + 4 GB ≈ 42 GB por VM, arredondando para 48 GB. Total: 96 GB.
3. Banco de dados: 8 vCPUs e memória suficiente para boa parte da base em cache, por exemplo 48 GB (limitando o SQL Server a cerca de 40 GB).
4. Aplicação do ERP: conforme o fabricante; em muitos casos 4 a 8 vCPUs e 16 GB.
5. Host: some a memória do hypervisor e, se usar ZFS, o cache ARC (limitável). Total aproximado: 96 + 48 + 16 + 8 a 16 GB ≈ 170 a 180 GB.
6. Disco: base, logs e perfis de usuário em NVMe espelhado; backup em outro local.

Com vCPUs, há margem para overcommit moderado se as cargas não tiverem pico ao mesmo tempo. Com memória, evite alocar mais do que o host tem.

Não esqueça do licenciamento

• Windows Server: licenciado pelos núcleos físicos do host; a edição define quantas VMs Windows você pode rodar.
• RDS CAL: uma licença de acesso por usuário ou por dispositivo para o Remote Desktop.
• Office em RDP: exige licenciamento por volume ou um plano Microsoft 365 com ativação em computador compartilhado.

Perguntas frequentes

Quantos usuários um servidor RDP aguenta?

Depende do perfil: de 1 a 6 usuários por vCPU pela referência da Microsoft. Um host de 16 vCPUs atende de algumas dezenas de usuários leves a poucos usuários intensivos.

O banco de dados pode ficar na mesma VM do RDP?

Pode, mas não é recomendado: um usuário pesado no RDP disputa CPU e memória com o banco e afeta todos. Separe em VMs diferentes.

É melhor mais núcleos ou núcleos mais rápidos?

Para RDP com muitos usuários, mais núcleos. Para rotinas do ERP que rodam em uma única thread (alguns relatórios e processamentos), a frequência de cada núcleo também conta.

Como saber se dimensionei certo?

Monitore após a migração: CPU média abaixo de 60% a 70% no pico, memória disponível sobrando, latência de disco baixa e atraso de entrada nas sessões RDP abaixo de 200 ms.

Leitura complementar

• Microsoft: diretrizes de dimensionamento de hosts de sessão
• Microsoft: contadores de desempenho para hosts de sessão
• TDN TOTVS: documentação do Protheus

Precisa de ajuda?

A E-Consulters oferece servidores dedicados usados para ERP, bancos de dados e RDP. Se quiser apoio para chegar a uma configuração a partir dos seus números, fale com o nosso comercial. Se você já é cliente, abra um ticket.