Sankhya travando: como diagnosticar a causa raiz da lentidão

Toda manhã, em alguma empresa que opera com o ERP Sankhya, alguém abre a tela de pedido, clica em salvar e fica olhando o cursor girar por trinta segundos. No dia seguinte, o mesmo lançamento leva três segundos. Na sexta à tarde, a tela cai e o time inteiro fica parado. Esse padrão errático tem nome técnico: gargalo intermitente — e quase nunca é culpa de uma única coisa.

Este guia foi escrito pela equipe da Nuuv Cloud com base nos diagnósticos que rodamos em ambientes produtivos de Sankhya ao longo dos últimos anos. O objetivo é dar a você uma trilha prática para identificar a causa raiz da lentidão antes de tomar qualquer decisão drástica — como trocar o servidor, ampliar a licença ou culpar o fornecedor.

Sintomas mais comuns de um Sankhya travando

Antes de mergulhar em causas, vale separar os sintomas em famílias. Cada família aponta para um conjunto diferente de culpados:

• Lentidão geral, o dia todo: indica subdimensionamento de infraestrutura ou banco de dados sem manutenção (estatísticas desatualizadas, índices fragmentados).

• Lentidão em horários específicos: aponta para jobs concorrentes — geralmente rotinas de integração, geração de relatórios ou backup rodando junto com o pico de uso.

• Sessões caindo a cada poucos minutos: sintoma clássico de problema de rede, timeout de proxy reverso ou heap do JBoss estourando e fazendo full GC.

• Travamentos em telas específicas: quase sempre é customização mal escrita — botão de ação chamando consulta sem índice, ou STP rodando em loop.

• Tudo trava ao gerar um relatório pesado: falta de isolamento entre OLTP (operação) e OLAP (relatório). O relatório engole toda a CPU do banco.

Causa 1 — JBoss mal dimensionado: heap, garbage collector e threads

O servidor de aplicação do Sankhya roda sobre JBoss/WildFly, e a maior parte dos travamentos que vemos em campo começa aqui. Três pontos para verificar:

Heap subdimensionado. O valor padrão de -Xmx (memória máxima) raramente é suficiente para ambientes com mais de 30 usuários simultâneos. Quando o heap fica cheio, o garbage collector entra em modo full GC e congela a JVM inteira por alguns segundos. Para checar, abra o standalone.conf e procure por -Xms e -Xmx. Como regra de bolso, comece com -Xms4g -Xmx8g para ambientes médios e ajuste a partir do GC log.

Pool de conexões estourado. O datasource do Sankhya tem um max-pool-size. Se ele for menor que o número de usuários ativos × consultas simultâneas, requisições ficam na fila esperando conexão livre. O log do JBoss vai mostrar mensagens tipo 'IJ000453: Unable to get managed connection'. Aumentar o pool resolve o sintoma, mas a causa raiz costuma ser query lenta segurando a conexão — investigue antes de só subir o número.

Threads bloqueadas. Um thread dump tirado no momento da lentidão (jstack <pid> > dump.txt) revela se há threads em BLOCKED waiting on lock. Esse é o smoking gun para identificar deadlocks de aplicação ou contenção em singletons do Sankhya.

Causa 2 — Banco de dados Oracle: conexões, índices e IOPS

Se a JVM está saudável e a lentidão persiste, o próximo suspeito é o banco. O Sankhya tem uma estrutura relacional grande e suporta tanto Oracle quanto SQL Server. Em ambos, três verificações pagam quase sempre:

Estatísticas desatualizadas. O otimizador de consultas decide o plano de execução com base nas estatísticas das tabelas. Se elas estão velhas, o banco pode escolher fazer full scan em uma tabela de milhões de linhas em vez de usar o índice. No Oracle, rodar DBMS_STATS.GATHER_SCHEMA_STATS no schema do Sankhya semanalmente é o mínimo. No SQL Server, equivalente é UPDATE STATISTICS.

Índices ausentes ou fragmentados. Customizações que filtram por colunas sem índice destroem a performance. Use o AWR (Oracle) ou Query Store (SQL Server) para identificar as top 10 consultas por tempo decorrido e veja se cada uma tem índice adequado nas colunas dos predicados WHERE e JOIN.

IOPS do disco. Banco de dados é I/O intensivo. Se os arquivos de dados estão em disco com IOPS baixo (comum em VPS genérico ou storage compartilhado mal dimensionado), todo SELECT vira espera de disco. Em ambiente cloud, o sintoma é o IOWAIT do sistema operacional acima de 20%. A solução é mover datafiles para storage NVMe ou aumentar a baseline de IOPS do volume.

Causa 3 — Infraestrutura: CPU, memória, disco e rede

Aqui mora um conjunto de problemas que muita empresa só descobre depois de meses gastando consultoria tentando 'otimizar o Sankhya'. Pontos que valem checar antes de qualquer outra coisa:

• CPU saturada em horário comercial. Rode top ou htop e veja se algum core fica em 100% por mais de alguns segundos. CPU 'congestionada' por GC do Java ou processo Oracle é sinal claro de subdimensionamento.

• Memória swappando. Se o sistema operacional começa a usar swap (disco como RAM), a lentidão é catastrófica. free -m e vmstat 1 mostram isso em segundos.

• Latência de rede entre app server e banco. App e banco em servidores diferentes só funcionam bem se a latência for inferior a 2ms. Acima disso, cada consulta paga o custo da rede. Teste com ping e tnsping (Oracle).

• Antivírus ou backup rodando no horário errado. Já vimos cliente com Sankhya travando todo dia às 14h — era o agente de backup tirando snapshot completo do disco do banco.

Causa 4 — Customizações e integrações pesadas

Sankhya permite STPs (procedures), regras, botões de ação e integrações via API. Cada customização é um vetor de risco. Os padrões que mais derrubam ambientes:

• STP que faz LOOP dentro de cursor em tabela grande, sem commit intermediário, segurando lock.

• Botão de ação que chama dezenas de consultas em sequência em vez de uma única consulta agregada.

• Integração externa (e-commerce, marketplace, fiscal) que chama LoadRecords com tamanho de página alto e sem paginação inteligente, gerando carga constante no banco.

• Job agendado mal dimensionado: gerar 500 boletos às 8h em ponto, exatamente quando todo mundo está logando.

O ponto importante: customização lenta não é problema da Sankhya, e nenhum servidor mais potente vai resolver. O diagnóstico precisa identificar o autor real do gargalo.

Checklist prático: 8 passos para isolar a causa

Quando o ambiente está travando, siga essa ordem. Cada passo elimina uma família inteira de suspeitos:

• 1. Tire um screenshot do top no servidor de aplicação e no servidor de banco no momento da lentidão. Salve com timestamp.

• 2. Verifique o IOWAIT do SO. Se estiver alto, o problema é disco do banco.

• 3. Veja o GC log do JBoss. Se há full GC frequente, suba o heap.

• 4. Capture um thread dump do JBoss (jstack). Procure por BLOCKED e contention.

• 5. Rode o AWR ou Query Store nas últimas 24h. Identifique as 10 queries que mais consumiram tempo.

• 6. Para cada query top, gere o plano de execução. Procure por full table scan onde deveria ter index seek.

• 7. Confirme que as estatísticas do banco foram coletadas recentemente.

• 8. Cruze os horários de lentidão com a agenda de jobs internos (backup, integrações, scheduled jobs do Sankhya). Coincidência aqui é causalidade.

Em 9 de cada 10 casos, esses oito passos já apontam a causa raiz. Os 10% restantes envolvem problemas mais sutis — corrupção lógica de bloco no Oracle, bug de driver JDBC, vazamento de memória em customização — e aí o caminho é abrir chamado técnico com quem opera a infra.

Quando o problema é a infraestrutura (e não o ERP)

Existe um padrão claro de quando trocar de servidor ou migrar para um provedor especializado vale a pena: quando os passos 1, 2, 3 e 4 do checklist apontam consistentemente para saturação de hardware, e não para customização ou query problemática.

Nesse cenário, ambientes hospedados em VPS genérico ou servidor on-premises antigo geralmente esbarram em três tetos: IOPS limitado do storage, CPU compartilhada com outros tenants e ausência de monitoramento contínuo que permita ajuste fino. Mudar para uma infraestrutura dedicada e dimensionada para o perfil de carga do ERP resolve o gargalo estrutural — mas só faz sentido depois que o diagnóstico provou que o problema realmente está na camada de infra.

Como a Nuuv Cloud pode ajudar

A Nuuv Cloud é uma empresa independente de infraestrutura em nuvem com foco em ambientes de ERP de missão crítica. Quando um cliente nos procura com sintomas de lentidão, a primeira coisa que fazemos não é vender servidor — é rodar o diagnóstico descrito acima. Em boa parte dos casos, a solução está em ajuste de configuração e otimização de queries, não em migração de ambiente.

Quando o diagnóstico aponta que a infra realmente é o gargalo, oferecemos ambiente dedicado com storage NVMe, monitoramento 24/7 com alertas proativos, DBAs especializados em Oracle e SQL Server, rotinas de backup compatíveis com LGPD e SLA contratual. O resultado prático: o time da empresa volta a focar em negócio, e o ambiente para de ser pauta nas reuniões de diretoria.

Se você está enfrentando os sintomas descritos neste artigo e quer uma avaliação técnica independente, entre em contato pelo site nuuv.cloud. Fazemos o levantamento inicial sem custo e devolvemos um relatório com a causa raiz identificada e as opções de tratamento.

Aviso: A Nuuv Cloud é uma empresa independente de prestação de serviços de infraestrutura em nuvem. Não possuímos vínculo, parceria, representação ou endosso de qualquer fabricante de software mencionado neste artigo. Todas as possíveis marcas citadas pertencem aos seus respectivos proprietários.