Protheus lento: 8 pontos que você deve verificar antes de culpar o servidor
Quando o Protheus fica lento a primeira reação de muita gente é apontar o dedo para o servidor: “É o servidor que está pesado”. Antes de abrir chamado e bater o martelo, dá para fazer uma checagem prática e rápida que evita retrabalho, resolve problemas comuns e, às vezes, mostra que a culpa estava em outro lugar. Neste post eu vou te guiar por 8 pontos concretos que você deve verificar — com exemplos do dia a dia e orientações simples — para descobrir a real causa da lentidão.
Como começar: reproduza o problema e descreva o cenário
Antes de qualquer teste técnico, pare, observe e documente. Pergunte ao usuário: em que tela demora? É em um relatório específico? A lentidão é contínua ou só em horários de pico? Isso parece óbvio, mas muitas soluções surgem só por entender melhor quando e como o problema aparece.
Exemplo prático: Maria reclama que “o Protheus está lento”. Ao perguntar, ela diz: “só quando tento emitir o relatório de faturamento às 17h”. Isso já é pista — um relatório pesado em horário de pico pode coincidir com processamento de fechamento ou backup, e não necessariamente é culpa do servidor de aplicação.
1. Diferencie: lento para todos ou só para alguns usuários/estações
Primeiro filtro: o problema é geral ou localizado?
- Se todos sentem lentidão ao mesmo tempo, é mais provável que seja algo no servidor, banco de dados ou na rede central.
- Se só alguns usuários têm problema, verifique a estação de trabalho, Wi‑Fi, antivírus, VPN, ou perfil do usuário no Protheus.
Exemplo do dia a dia: João no caixa reclama que o módulo de vendas demora. Você testa na máquina do suporte e está normal — a causa pode ser a rede local do caixa (switch, cabo, interferência Wi‑Fi) ou um anti‑vírus que está verificando os executáveis do Protheus.
2. Rede e conexão: latência, perda de pacotes e DNS
Rede é a “rua” por onde os dados viajam. Mesmo com servidor top, se a rua estiver congestionada, o tráfego engarrafa.
O que verificar:
- Ping e traceroute: meça latência e veja se há saltos muito longos. Pequenas latências (<20 ms na rede local) são normais; latências altas (>100 ms) prejudicam aplicações interativas.
- Perda de pacotes: perda ocasional atrasa retransmissões. 1% já é ruim para aplicações ERP.
- DNS: resoluções lentas atrasam conexões. Teste com IP direto para checar.
- Rede Wi‑Fi vs cabo: estações críticas (caixa, alta rotatividade) funcionam melhor via cabo.
Exemplo: Durante horário de pico, muitos usuários usam a mesma VLAN para backup ou sincronização de arquivos; o tráfego pesado congela respostas do Protheus. Migrar backups para janela fora do horário de pico ou limitar banda resolve o gargalo.
3. Banco de dados: consultas lentas, índices e estatísticas
Grande parte da lentidão do Protheus está ligada ao banco de dados. O sistema faz muitas consultas; uma query ruim atrasa toda a tela.
O básico a checar:
- Identifique telas/relatórios lentos e peça o relatório de queries longas ao DBA (ou use monitor de queries). Um SELECT que faz varredura completa numa tabela grande é um sinal de falta de índice.
- Verifique índices e estatísticas atualizadas. Para bancos grandes, índices fragmentados ou estatísticas desatualizadas causam planos de execução ruins.
- Bloqueios e deadlocks: transações longas podem manter locks e travar outros usuários.
- Configuração de conexão: número de conexões simultâneas, pooling e timeout influenciam desempenho.
Exemplo cotidiano: Um relatório de comissão consulta a tabela de notas fiscais sem filtro e faz full scan: em 100.000 notas, isso vira minutos. Criar índice adequado ou ajustar a query reduz de minutos para segundos.
4. Servidor de aplicação Protheus: parâmetros, threads e versão
O servidor de aplicação (AppServer) tem configurações que impactam performance: número de threads, timeout de sessão, memória utilizada pelo serviço e versão do Protheus.
Pontos práticos:
- Versão e patch: bugs de performance são corrigidos em releases/packs. Verifique se há patch recomendado pela TOTVS para sua versão.
- Número de threads/processos: se estiver configurado abaixo do ideal, o servidor enfileira requisições; se estiver acima, pode saturar CPU e memória.
- Logs do AppServer: verifique erros, warnings e tempos de execução de chamadas.
- Reinício programado: servidores com semanas sem reiniciar podem acumular memória perdida (memory leak) — reiniciar no horário de menor uso pode devolver performance imediata.
Exemplo: O AppServer está com número de threads limitado a 5 por instância. Com 20 usuários simultâneos, pedidos ficam esperando. Ajustar para 20 threads (considerando CPU/memória disponíveis) resolve o gargalo de enfileiramento.
5. Estações de trabalho e ambiente local (PCs, antivírus, rede Wi‑Fi)
Muitas vezes o problema está mais perto do que você imagina: no computador do usuário.
O que checar:
- Desempenho do PC: CPU em 100% por outros processos, memória cheia, disco lento (HDD cheio ou com problemas) podem deixar o cliente Protheus lento.
- Antivírus: alguns antivírus fazem escaneamento em execução de programas e em arquivos temporários do Protheus — adicione exclusões para diretórios do Protheus e arquivos executáveis.
- Versão do SmartClient/Web: clientes desatualizados podem ter bugs de performance. Atualize conforme orientação da TOTVS.
- Conexão VPN: VPNs com má configuração aumentam latência; para empresas que usam VPN, verifique a qualidade do túnel.
Exemplo prático: Um caixa que abre o módulo de vendas e fica lento tinha um antivírus configurado para escanear todos os executáveis na pasta do Protheus a cada execução. Ao criar exclusão para a pasta do cliente, a lentidão desapareceu.
6. Relatórios, exports e integrações externas
Relatórios complexos, processamento de arquivos grandes, integrações com outros sistemas e spool de impressão podem ser responsáveis por picos de lentidão.
Verifique:
- Relatórios agendados em horários de uso: se um relatório pesado roda simultaneamente ao expediente, todo mundo sofre. Reagende para horários fora do pico.
- Geração de arquivos (XML, Excel, PDFs): criação e gravação de arquivos em rede pode sobrecarregar storage e rede.
- Integrações síncronas: chamadas a APIs externas que demoram (pagamento, verificação fiscal) travam a operação. Sempre prefira chamadas assíncronas quando possível.
- Spool e filas de impressão: spools grandes acumulados diminuem performance; limpe/rotacione regularmente.
Exemplo: Relatório de conferência fiscal programado para 10h encaixa com pico de faturamento. Resultado: todos os caixas lentos. Mudança para 2h da manhã eliminou o impacto.
7. Customizações, rotinas e códigos personalizados
Personalizações (RM, logs, funções escritas pela equipe, customizações em ADVPL) podem ser fonte de lentidão se não forem otimizadas.
O que observar:
- Código loop sem limite ou consultas dentro de loop que geram N+1 queries.
- Funções que escrevem muitos logs em disco sem rotação, enchendo o storage.
- Atualizações em tabelas grandes sem índices ou sem controle de lote (bulk updates podem travar).
- Deploys recentes: ao introduzir uma versão customizada nova, verifique se a lentidão começou após isso.
Exemplo cotidiano: Um script que atualiza itens em estoque fazia um SELECT por produto dentro de um loop. Para 5.000 produtos, eram 5.000 queries. Reescrever para usar JOINs e updates em lote reduziu de horas para minutos.
8. Logs, cache, disco e quando realmente é o servidor
Por fim, verifique logs, uso de disco e indicadores do servidor. Só depois de eliminar os itens anteriores vale apontar o servidor como culpado.
Passos objetivos:
- Monitore CPU e memória: uso constante acima de 80% na CPU ou memória insuficiente levando a swap é sinal claro de sobrecarga.
- Disco e IO: latência de disco alta (I/O wait) deixa tudo lento. Storage compartilhado saturado afeta o banco de dados.
- Logs de aplicação e do banco: erros repetidos, timeouts e rollbacks aparecem aqui.
- Processos zumbis ou consumo anômalo: um processo mal comportado pode sugar recursos; identifique e reinicie se for seguro.
- Ambiente virtualizado: má configuração do hypervisor (limitação de CPU, CPU steal) também causa lentidão.
Como saber que é problema do servidor e não de outra coisa? Alguns sinais fortes:
- Todos os sistemas hospedados no mesmo servidor apresentam lentidão ao mesmo tempo.
- Métricas de CPU, memória e disco mostram saturação contínua correlacionada com os horários de lentidão.
- Mesmo com clientes locais otimizados, queries analisadas pelo DBA mostram demora por espera em I/O do disco.
Exemplo: O servidor de banco apresentou I/O wait elevado por horas durante horário de pico. Investigando, descobriu-se que o storage tinha um longo backlog por causa de backup concorrente. Mover backup para outra janela e otimizar policias de snapshot resolveu o problema.
Checklist rápido: ordem prática para investigação
Use esta ordem para diagnosticar sem dor de cabeça:
- Reproduza o problema e identifique tela/relatório afetado.
- Verifique se é geral ou só em algumas estações.
- Teste rede (ping, tracert), confirme latência e perda de pacotes.
- Cheque estação de trabalho (CPU, memória, antivírus, cabo/Wi‑Fi).
- Pergunte ao DBA sobre queries longas, índices e bloqueios.
- Verifique AppServer: threads, logs, versão e reinício programado.
- Analise relatórios agendados, integrações e spoolers em horário de pico.
- Somente depois verifique métricas do servidor (CPU, memória, disco) e storage.
Seguindo esta ordem você economiza tempo e evita abrir chamados desnecessários com o time de infraestrutura ou com o fornecedor.
Bom senso: priorize ações de baixo custo e alto impacto
Nem tudo precisa de intervenção do time de infraestrutura. Comece com o que dá resultado rápido: exclusão de antivírus, mover relatórios, ajustar índices simples, reiniciar um serviço em horário de menor uso. Mesmo pequenas intervenções costumam melhorar a experiência do usuário.
Quando envolver o time de TI/fornecedor:
- Se você identificou CPU/memória/disco saturado no servidor.
- Se há problemas de storage (alta latência, I/O wait) ou de rede interna que você não consegue isolar.
- Se após todas as checagens persistir lentidão e logs mostrarem timeouts e erros de infraestrutura.
Exemplo: Em uma loja com pico de vendas, a solução imediata foi alterar a janela de execução de relatórios e adicionar exclusões de antivírus — ação do usuário/suporte local. Depois, a TI precisou ajustar reserva de IOPS no storage para prevenir reincidência durante promoções futuras.
Conclusão: investigue com método antes de culpar o servidor
O servidor às vezes é realmente o responsável, mas muitas causas comuns estão mais próximas: rede, banco de dados, estação do usuário, relatórios ou customizações. Seguir um roteiro simples de diagnóstico ajuda a encontrar a causa mais rápido e a implantar a solução certa — sem troca de servidor desnecessária ou perda de tempo.
Se quiser, posso te ajudar a montar um checklist personalizado para o seu ambiente Protheus: me diga qual versão vocês usam, onde está o banco (Oracle, SQL Server, Postgres) e se usam AppServer ou ambiente em nuvem — com essas infos eu te retorno com um passo‑a‑passo ainda mais prático.
