Sankhya na cloud: arquitetura correta e sizing
A arquitetura correta para Sankhya em cloud exige separação obrigatória entre servidor de aplicação (Tomcat ou WildFly/JBoss com a JVM do Sankhya) e servidor de banco de dados (Oracle ou SQL Server) em VMs distintas. Rodar ambos na mesma VM causa competição por RAM que resulta em GC frequente na JVM e buffer pool insuficiente no banco, os dois problemas de performance mais comuns no Sankhya.
Com JVM e banco na mesma VM, qualquer pico de uso aumenta a pressão de memória nos dois lados. A JVM começa a fazer GC mais frequente e o banco perde buffer pool, combinação que paralisa o sistema para todos os usuários simultâneos.
Muitos ambientes Sankhya são instalados com -Xmx padrão de 2 ou 4 GB, valor adequado apenas para demos e pequenos pilotos. Ambientes produtivos com 20+ usuários precisam de 8 a 16 GB de heap para evitar GC excessivo.
O Sankhya realiza leituras frequentes de metadados e cache no banco durante a navegação. Com latência variável de storage em pool, o comportamento do sistema fica imprevisível, rápido às vezes, lento outras vezes, sem causa aparente.
Provisione VM dedicada para o servidor de aplicação Sankhya. Configure -Xms e -Xmx com valores iguais (sem redimensionamento dinâmico), use G1GC e monitore o heap utilization nas primeiras semanas para ajustar.
Provisione VM separada para o banco com NVMe dedicado. No SQL Server, separe volumes de dados e logs. No Oracle, use ASM ou volumes dedicados para datafiles e redo logs.
O Sankhya faz muitos round-trips entre App e DB por operação de usuário. Com latência de rede interna acima de 2 ms, esse overhead se acumula e aumenta o tempo de resposta. Mantenha App e DB na mesma rede interna do datacenter.
Configure alertas para heap usage acima de 80% e GC overhead acima de 5%. Problemas de heap crescem progressivamente, identificar cedo evita incidentes de produção com OOM (Out of Memory) do servidor.
A Boreal Tecnologias provisiona ambientes Sankhya com arquitetura separada (App + DB), NVMe dedicado e rede interna de baixa latência. Diagnóstico gratuito do ambiente atual e migração assistida, cloud privada no Brasil com SLA 99,99% e preço em reais.
O Sankhya (Tomcat ou WildFly) roda em Linux, e muitos ambientes produtivos usam Linux para o servidor de aplicação, especialmente com banco Oracle. Windows é necessário apenas para o SQL Server (que também tem versão Linux) ou para integrações que dependem de componentes Windows específicos.
Tomcat é o servidor de aplicação mais comum para Sankhya e tem footprint menor. WildFly (JBoss) é usado em configurações enterprise com clustering e failover. Para a maioria das empresas, Tomcat com configuração adequada de heap e G1GC é suficiente e mais simples de operar.
Sim, Sankhya oferece a modalidade SaaS (Sankhya Cloud) gerenciada pela própria Sankhya. Para empresas que precisam de controle sobre os dados, integrações customizadas ou compliance específico (LGPD, setor regulado), o modelo IaaS com cloud privada própria continua relevante.
O mínimo para alta disponibilidade é backup automático do banco a cada 4 horas, monitoramento do Tomcat com restart automático em caso de falha e uma VM de standby com backup restaurado para RTO de 1 a 2 horas. Clustering ativo-ativo do Tomcat é possível mas complexo, a maioria das empresas aceita RTO de até 30 minutos com restore manual.
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.