Sankhya lento: causas reais (Java, GC, banco, I/O) e como resolver
Sankhya lento é frequentemente causado por Java heap subdimensionado provocando Garbage Collection (GC) pausas frequentes, cada Full GC pode paralisar o servidor por 2 a 30 segundos dependendo do tamanho do heap. O segundo fator mais comum é I/O de disco com alta latência no banco de dados (Oracle ou SQL Server), que amplifica os efeitos de queries ineficientes que rodam bem em ambientes com storage rápido.
O Sankhya roda em JVM (Tomcat ou JBoss/WildFly). Com heap insuficiente, a JVM executa Full GC com frequência, pausas que bloqueiam todas as threads da aplicação por segundos. O sintoma é lentidão intermitente acompanhada de picos de CPU.
Queries analíticas e relatórios do Sankhya geram leituras intensas no banco. Com storage compartilhado e latência acima de 5 ms, cada query demora proporcionalmente mais, e o efeito se multiplica em relatórios que executam dezenas de queries.
Oracle e SQL Server usam estatísticas de tabelas para gerar planos de execução eficientes. Com estatísticas desatualizadas em tabelas grandes do Sankhya (TGFCAB, TGFITE), o otimizador escolhe planos ruins que fazem full table scan onde deveria usar índice.
Configure -Xms (heap inicial) e -Xmx (heap máximo) com valores iguais para evitar redimensionamento dinâmico. Para ambientes com até 50 usuários, -Xmx8g é um ponto de partida; monitore o uso real com jstat ou VisualVM e ajuste.
Troque o GC padrão pelo G1GC (-XX:+UseG1GC) ou ZGC (-XX:+UseZGC no Java 15+). O G1GC mantém pausas abaixo de 200 ms mesmo com heaps grandes, diferença crítica para a experiência do usuário do Sankhya.
Migrar o banco para NVMe dedicado reduz a latência de I/O de dezenas de milissegundos para abaixo de 500 µs, impacto imediato nas queries mais lentas do Sankhya sem nenhuma mudança de código.
Execute UPDATE STATISTICS (SQL Server) ou GATHER STATS (Oracle) nas tabelas de cabeçalho e itens de pedido/nota fiscal periodicamente. Verifique os índices das tabelas TGFCAB e TGFITE com o DBA, índices ausentes são causa comum de lentidão em consultas de vendas.
A Boreal Tecnologias oferece diagnóstico gratuito de ambientes Sankhya, analisando o heap da JVM, GC logs e métricas de I/O do banco. Nossa cloud privada no Brasil fornece VMs com NVMe dedicado, vCPU sem overcommit e SLA 99,99% em reais.
Não existe um valor único, depende do número de usuários, módulos ativos e volume de dados. O ponto de partida é 8 GB para até 50 usuários. Monitore o uso real com jstat -gcutil a cada 5 segundos durante pico de uso e ajuste -Xmx até que o GC overhead fique abaixo de 5% do tempo total.
Depende do sintoma. Lentidão intermitente sincronizada com logs de GC é problema de heap/JVM, infraestrutura. Lentidão específica em uma tela ou relatório geralmente é query ineficiente, aplicação/banco. As duas causas coexistem frequentemente; o diagnóstico correto requer análise de GC logs e wait statistics do banco simultaneamente.
Ambos são suportados e performam de forma similar quando bem configurados. O Oracle tem vantagem em análises complexas com grandes volumes; o SQL Server tem menor custo de licença e mais profissionais disponíveis no Brasil. A maioria das empresas que migra do Oracle para SQL Server não percebe diferença de performance após otimização de queries e índices.
Habilite o GC log no start do Tomcat com -Xloggc:/path/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps. Analise os logs com ferramentas como GCEasy ou GCViewer. Full GC acima de 1 vez por minuto ou pausas acima de 1 segundo são sinal claro de heap subdimensionado.
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.