Fluig lento ou travando: como achar a causa

Quando o Fluig fica lento, a primeira reação costuma ser pedir mais memória ou reiniciar o servidor. Às vezes isso alivia por alguns dias, mas a causa continua lá. O caminho que funciona é delimitar o problema, medir e só depois mexer.

Este roteiro segue a ordem da página de avaliação de lentidão da TOTVS, com os passos seguintes para os casos mais difíceis.

Antes de começar: uma pessoa ou todo mundo?

A primeira pergunta divide a investigação em dois caminhos:

• Lento em uma tela ou processo específico: provavelmente é uma customização, um dataset ou uma integração.
• Tudo lento para todo mundo: olhe para o servidor, com memória, CPU e banco de dados.

Anote também quando começou. Publicação de processo, atualização de versão ou aumento de volume perto dessa data são as primeiras pistas.

1. Use o navegador para localizar a demora

Abra as ferramentas do navegador (F12), aba Rede, e repita a ação lenta. Assim você identifica qual requisição demora e separa os casos:

• Recursos externos, como uma biblioteca JavaScript carregada no formulário.
• Requisições internas, que levam a investigação para o servidor.

Se a tela demora mas nenhuma requisição está lenta, o problema pode estar no próprio navegador, como um dataset grande demais sendo montado no formulário.

2. Saiba o que costuma pesar em cada tela

A TOTVS descreve os cenários mais comuns:

Na abertura de um processo. Verifique eventos de formulário (displayFields, enableFields), eventos do tipo before, consultas a dataset e chamadas externas.

Ao enviar uma solicitação. Verifique eventos do tipo after, validação de formulário (validateForm) e integrações com sistemas externos.

Na tela de iniciar processos. Os mecanismos de atribuição das atividades iniciais podem causar demora.

Em documentos. Verifique eventos personalizados e, se a demora for no visualizador interno, o dimensionamento dele.

Na página inicial. Avalie o tempo de execução de widgets e páginas desenvolvidas.

3. Meça as customizações com JSChronos

O log do servidor registra o tempo de execução das customizações. Procure por JSChronos ou por executou por:

INFO [com.totvs.technology.foundation.common.JSChronos] (http-pool-threads - 77) DatasetFactory.getDataset.dsCargosSalariosAtv executou por 1 segundo
INFO [com.totvs.technology.foundation.common.JSChronos] (http-pool-threads - 95) CustomizationManagerImpl.invokeFunction.validateForm executou por 1 segundo

Liste as customizações mais lentas e as mais frequentes. Um dataset de 2 segundos chamado a cada abertura de formulário pode pesar mais que um de 30 segundos que roda uma vez por dia.

A localização do server.log varia conforme a versão. Consulte a documentação da sua: costuma ser appserver/standalone/log nas versões mais recentes e appserver/domain/servers/fluig1/log em versões anteriores à 2.0.

O Fluig também permite ativar log por usuário em Painel de Controle → Gerais → Controle de log, útil quando o problema aparece para uma pessoa só.

Com os culpados em mãos, as correções mais comuns são:

• Dataset: filtrar na origem, limitar colunas e avaliar sincronização. Veja o guia de dataset no Fluig.
• Evento: reduzir o processamento. Veja a ordem dos eventos de processo.
• Integração: usar a Atividade de Serviço, que é a recomendação da TOTVS para esses casos.

4. Quando o servidor trava: CPU em 100%

Quando o log não explica e a plataforma inteira para, é hora de olhar para dentro da JVM. O Fluig é uma aplicação Java, então valem as ferramentas padrão do JDK.

Colete antes de reiniciar. Reiniciar apaga as evidências. Se possível, tenha um procedimento pronto para coletar os dados no momento do incidente.

Descubra se é aplicação ou coleta de lixo. CPU alta costuma ter duas causas diferentes: threads presas em um processamento, ou a JVM sem memória, gastando CPU para tentar liberar espaço. A correção de uma não serve para a outra. O jstat responde rápido:

jstat -gcutil <PID> 2000 5

Se a coluna da old generation fica perto de 100% e as coletas completas se repetem, o problema é memória. Atenção: nem sempre aparece OutOfMemoryError no log. Em um incidente que analisamos, houve apenas lentidão crescente até a plataforma parar, com a JVM gastando a maior parte do tempo em coleta de lixo.

Thread dump: o que está rodando agora. Em Linux, identifique as threads que mais consomem CPU e colete o dump:

top -H -p <PID>
jcmd <PID> Thread.print > threads.txt

Converta o ID da thread para hexadecimal e procure no arquivo pelo campo nid:

printf '%x\n' <ID_DA_THREAD>

Colete dois ou três dumps com alguns segundos de intervalo. Threads que continuam no mesmo ponto em todos eles mostram onde a aplicação está presa.

Heap dump: o que está ocupando a memória. Quando a suspeita é memória, o heap dump mostra quais objetos estão acumulados:

jcmd <PID> GC.heap_dump /caminho/com/espaco/fluig.hprof

Três cuidados importantes:

• O comando pausa a aplicação e gera um arquivo próximo do tamanho do heap em uso. Confira o espaço em disco.
• Faça isso em um momento planejado ou durante um incidente que já esteja parando a operação.
• O arquivo contém dados vivos da aplicação, inclusive dados pessoais e possivelmente credenciais. Trate-o como informação sensível.

Analise com o Eclipse Memory Analyzer. O MAT tem um relatório de suspeitos de vazamento que aponta os objetos que mais retêm memória. Em geral, é o caminho mais curto até o componente responsável.

O caso: um travamento, duas equipes, uma causa

Em um dos casos que atendemos, o servidor travava toda semana, com CPU em 100% e o fornecedor sem resposta. O heap dump da aplicação mostrou o componente que acumulava objetos em memória. Mais que isso: revelou que a mesma falha de integração que gerava erros em outra frente alimentava o travamento.

Dois incidentes, tratados por equipes diferentes, eram uma causa só. E o fornecedor passou a receber evidência, não suspeita.

Em outro ambiente, o heap dump mostrou milhares de sessões HTTP que não expiravam, criadas pelo uso do aplicativo móvel. O mesmo quadro voltou semanas depois, o que confirmou o padrão: sem tratar a causa, o reinício só marca a data do próximo incidente. Um incidente assim também pode ter efeito colateral: quando o pool de conexões caiu, solicitações abertas automaticamente por integração sofreram rollback. Depois de um travamento, verifique o que deixou de entrar.

Essa é a lição mais prática: integração com erro não costuma falhar sozinha. Filas crescem, objetos ficam retidos e a pressão aparece em outro lugar. Um exemplo é o que discutimos em pedidos duplicados na integração.

E aumentar a memória, resolve?

Às vezes, sim. Se o ambiente está abaixo do modelo de dimensionamento, ajustar é o certo. O arquivo de configuração muda conforme a versão, então confira a documentação da sua antes de alterar.

Mas se existe um vazamento ou um acúmulo, mais memória só aumenta o intervalo entre os travamentos e deixa cada coleta de lixo mais longa. Primeiro entenda o que está consumindo.

Perguntas frequentes

Por que o Fluig fica lento só em alguns horários?

Olhe para o que roda nesses horários: rotinas agendadas, sincronização de datasets, picos de uso e backups. Compare os horários com o log.

Reiniciar o Fluig resolve?

Alivia sintomas de memória, mas não resolve a causa. Se o reinício virou rotina, existe um problema a ser encontrado.

Quando abrir um chamado na TOTVS?

Quando a análise aponta para o produto, e não para customizações. Chegar com log, thread dump e heap dump costuma encurtar bastante o atendimento.

Se o seu Fluig trava e ninguém consegue explicar por quê, a MyQube faz esse diagnóstico com evidência, do log ao heap dump. Fale com a gente.