Sizing para Sankhya: Java heap, RAM, vCPU e banco por porte
Para Sankhya com até 50 usuários simultâneos, o sizing mínimo recomendado é: servidor de aplicação com 4 vCPU + 16 GB RAM (com -Xmx8g para o heap JVM) e servidor de banco com 8 vCPU + 32 GB RAM + NVMe dedicado. O Java heap deve ser dimensionado para ocupar no máximo 50% da RAM total do servidor de aplicação, os outros 50% cobrem o SO, o próprio Tomcat fora do heap e o metaspace da JVM.
O instalador do Sankhya frequentemente configura -Xmx com valores baixos como padrão. Esses valores funcionam em demos mas causam GC constante em ambiente produtivo com dezenas de usuários e histórico de dados real.
Além do heap (-Xmx), a JVM usa Metaspace (classes carregadas), Code Cache (JIT) e memória nativa. Em produção, o total de memória da JVM pode ser 1,5× o valor de -Xmx. Não contabilizar isso leva a pressão de memória no SO.
O banco Sankhya cresce com cada NF emitida, pedido registrado e lançamento contábil. Sem projeção de crescimento, o storage enche em 6 a 12 meses, evento crítico que pode corromper transações em andamento.
Configure -Xms8g -Xmx8g (heap fixo) e -XX:MetaspaceSize=512m no start do Tomcat. No banco, aloque 80% da RAM para o buffer pool (SQL Server) ou SGA (Oracle).
Com mais usuários e módulos ativos simultâneos, o heap precisa crescer proporcionalmente. Monitore o heap utilization nas primeiras semanas e ajuste -Xmx conforme necessário.
Habilite GC logging e colete dados por 2 semanas em produção antes de dimensionar. O perfil real de alocação de objetos varia significativamente por módulos usados, fiscal e manufatura têm comportamentos distintos de memória.
Estime o crescimento mensal do banco analisando o volume de NFs e transações atual. Provisione storage para 24 meses de crescimento mais 30% de folga, expansão de NVMe em cloud privada é transparente para a aplicação.
A Boreal Tecnologias dimensiona ambientes Sankhya com análise do perfil real de uso, módulos ativos, volume de NFs e histórico de crescimento do banco. Diagnóstico gratuito e cloud privada no Brasil com NVMe dedicado e SLA 99,99% em reais.
Comece com -Xmx12g em um servidor de 24 GB RAM (50% para heap, 50% para SO e metaspace). Monitore com jstat -gcutil e ajuste, se o heap usado raramente passa de 70%, o valor está correto. Se chega a 90%+ frequentemente, aumente -Xmx.
G1GC (-XX:+UseG1GC) é a escolha mais segura e compatível com Java 8+, o mais usado no Sankhya. ZGC é superior em latência mas requer Java 15+ e tem comportamento menos documentado com o Sankhya. Para a maioria dos ambientes, G1GC com -XX:MaxGCPauseMillis=200 é a configuração ideal.
Para ambientes acima de 20 usuários simultâneos, sim. Com App e banco na mesma VM, a RAM total disponível precisa cobrir tanto o heap JVM quanto o buffer pool do banco, o que resulta em um servidor significativamente mais caro que dois servidores menores separados.
SSDs SATA entregam latência de 0,5 a 2 ms e IOPS de 50 a 100k. NVMe entrega latência abaixo de 100 µs e IOPS acima de 500k. Para o perfil de leitura aleatória do Sankhya, a diferença é perceptível, especialmente em relatórios analíticos e consultas de histórico.
Receba um diagnóstico estratégico gratuito e descubra o que está limitando performance, estabilidade e escala hoje.
Sem compromisso. Resposta em até 15 minutos em horário comercial.