Atualizado em
O TOTVS Protheus lento é uma das reclamações mais frequentes de equipes de TI. O problema é que “lento” pode ter origem em quatro camadas completamente diferentes — e tratar a camada errada não resolve nada. Este guia apresenta uma metodologia de diagnóstico por camadas para identificar onde está o gargalo antes de tomar qualquer decisão de investimento.
Neste artigo
- Metodologia de diagnóstico em camadas
- Camada 1 — Infraestrutura (servidor, storage, rede)
- Camada 2 — Banco de dados SQL Server
- Camada 3 — Aplicação (AppServer e DBAccess)
- Camada 4 — Customizações e código ADVPL
- Sintomas e causas prováveis — tabela de diagnóstico
- Quando migrar para cloud resolve a lentidão
- Perguntas frequentes
Metodologia de diagnóstico em camadas
Antes de comprar mais hardware, contratar cloud ou reinstalar o Protheus, é necessário identificar em qual das quatro camadas está o problema. Cada camada tem sintomas e ferramentas de diagnóstico próprios — e a solução muda completamente dependendo de onde está o gargalo.
| Camada | Componentes | Quem resolve |
|---|---|---|
| 1. Infraestrutura | Servidor, storage, rede, virtualização | Provedor de infraestrutura / TI interno |
| 2. Banco de dados | SQL Server, índices, estatísticas, queries | DBA / TI interno |
| 3. Aplicação | AppServer, DBAccess, configurações do Protheus | Parceiro TOTVS / TI interno |
| 4. Customizações | Código ADVPL, rotinas customizadas, integrações | Parceiro TOTVS / desenvolvedor |
Comece sempre pela camada 1
Diagnósticos de banco de dados e aplicação são desnecessários se o servidor está com CPU saturada ou o storage com IOPS insuficiente. Verifique a infraestrutura primeiro — é a camada mais rápida de medir e a mais comum nas reclamações de lentidão.
Camada 1 — Infraestrutura: servidor, storage e rede
CPU: saturação vs pico pontual
CPU constantemente acima de 80% indica subdimensionamento ou gargalo real. CPU em pico durante fechamentos e depois caindo é comportamento esperado — não necessariamente um problema de sizing. Monitore o percentual de CPU durante o horário de uso normal (não apenas durante incidentes) e verifique quais processos dominam o consumo.
storage como gargalo mais comum e menos visível
O indicador mais crítico para o Protheus é a latência de I/O do banco de dados — não a velocidade de leitura sequencial. Monitore a latência de disco no servidor SQL Server. Se a latência de I/O estiver consistentemente acima de 5ms durante a operação normal, o storage é o gargalo. Storages HDD ou SATA com baixo IOPS são a causa mais frequente de lentidão em ambientes Protheus antigos.
RAM: buffer pool do SQL Server
Verifique a pressão de memória no SQL Server — especificamente se o buffer pool está sendo constantemente pressionado (indicador: alta taxa de “page reads” físicos vs lógicos). RAM insuficiente força o SQL Server a carregar páginas do disco a cada operação.
Rede: latência entre terminal e AppServer
O Protheus é protocolo-intensivo entre o terminal do usuário e o AppServer. Latência acima de 10ms nesse trecho é perceptível como “travamento” de tela. Verifique também a latência entre AppServer e SQL Server — deve estar abaixo de 2ms.
Camada 2 — Banco de dados: SQL Server
Índices fragmentados
Índices fragmentados no banco do Protheus aumentam o tempo de consulta progressivamente. A manutenção de índices (rebuild ou reorganize) é uma tarefa de DBA que deve ser executada periodicamente — especialmente em bancos com alto volume transacional. Verifique quando foi a última vez que isso foi feito.
Estatísticas desatualizadas
Estatísticas desatualizadas fazem o otimizador do SQL Server escolher planos de execução ruins para as queries do Protheus. A atualização de estatísticas é uma manutenção simples que pode ter impacto significativo no desempenho.
Queries de longa duração
O SQL Server tem ferramentas nativas (Query Store, sys.dm_exec_query_stats) para identificar as queries que mais consomem tempo e recursos. Em muitos casos, uma única query mal otimizada pode causar lentidão percebida por todos os usuários.
Crescimento automático do banco
Banco de dados configurado com crescimento automático em incrementos pequenos (ex.: 1 MB ou 10%) gera operações frequentes de crescimento de arquivo — que interrompem temporariamente as transações. Configure o crescimento automático com incrementos maiores ou pré-aloque o espaço.
Camada 3 — Aplicação: AppServer e DBAccess
Número de conexões simultâneas no AppServer
Verifique se o AppServer está operando próximo do limite de conexões configurado. Cada sessão ativa consome threads e memória — se o limite for atingido, novas conexões são enfileiradas e o usuário percebe demora no login e nas operações.
Versão do AppServer e DBAccess
Versões antigas do AppServer e DBAccess têm bugs de desempenho que foram corrigidos em releases posteriores. Verifique se a versão instalada é compatível com a versão do Protheus e se há patches ou builds mais recentes disponíveis no portal da TOTVS.
Configuração do DBAccess
O DBAccess tem parâmetros de configuração (pool de conexões, timeout, número de threads) que afetam diretamente o desempenho. Uma configuração padrão que nunca foi revisada pode estar subdimensionada para o volume atual de usuários e transações.
Camada 4 — Customizações e código ADVPL
Customizações são frequentemente a causa de lentidão que mais demora a ser identificada — porque o problema não é da infra, não é do banco e não é do Protheus padrão. É do código que foi escrito especificamente para a empresa.
Os padrões mais comuns de código ADVPL que causam lentidão:
- Queries sem uso de índices — filtros que não usam as colunas indexadas, forçando full table scan
- Loops que executam queries por iteração — padrão N+1 que escala pessimamente com volume
- Transações abertas por muito tempo — seguram locks e bloqueiam outros usuários
- Uso excessivo de RecLock/UnLock — em volumes altos, gera contenção de bloqueios
- Integrações síncronas em rotinas de usuário — uma chamada externa lenta trava o terminal do usuário
Responsabilidade do parceiro TOTVS, não do provedor de infra
Problemas de código ADVPL são de responsabilidade do parceiro funcional ou do desenvolvedor interno que criou a customização — não do provedor de infraestrutura. Um servidor maior não resolve código ineficiente: apenas mascara o problema temporariamente e aumenta o custo.
Sintomas e causas prováveis — tabela de diagnóstico
| Sintoma | Causa mais provável | Camada | Verificação |
|---|---|---|---|
| Lentidão afeta todos os usuários ao mesmo tempo | CPU, IOPS ou rede saturados | Infra | Monitor de recursos do servidor |
| Lentidão só durante fechamento fiscal | Jobs batch concorrendo com operação; IOPS insuficiente | Infra / Banco | Monitorar CPU e IOPS durante o batch |
| Tela trava ao abrir determinado formulário | Query lenta no banco; customização com loop ineficiente | Banco / Custom. | Query Store ou trace do SQL Server |
| Login demorado | AppServer com muitas conexões; latência de rede | App / Infra | Conexões ativas no AppServer; ping ao AppServer |
| Lentidão só para usuários remotos | Latência de rede entre terminal e AppServer | Infra / Rede | Medir latência (ping) do site remoto ao AppServer |
| Lentidão progressiva ao longo do dia | Fragmentação de índices; crescimento automático do banco | Banco | Fragmentação de índices; eventos de crescimento de arquivo |
| Lentidão só em uma rotina específica | Código ADVPL mal otimizado; query sem índice | Custom. / Banco | Trace da rotina; análise do código ADVPL |
Quando migrar para cloud resolve a lentidão — e quando não resolve
Migrar para cloud tende a resolver quando:
- O storage atual é HDD ou SATA de baixo IOPS — cloud com All-Flash elimina esse gargalo
- O servidor não tem RAM suficiente para o buffer pool do SQL Server
- Usuários remotos têm latência alta por acessar um servidor local pela internet
- O ambiente não tem backup adequado e a empresa quer solução gerenciada
Migrar para cloud não vai resolver quando:
- O problema é código ADVPL mal otimizado — o código vai junto na migração
- Índices fragmentados ou estatísticas desatualizadas — precisam de manutenção de banco, não de novo hardware
- Configuração do AppServer ou DBAccess incorreta — configuração vai junto
- Queries do sistema ou customizadas com planos de execução ruins — o banco precisa ser revisado
Com lentidão no TOTVS Protheus?
A Adentro analisa a camada de infraestrutura e identifica se o problema está no storage, no servidor ou na rede — sem custo.
Solicitar análise Ver guia de sizingPerguntas frequentes
O Protheus fica mais rápido após upgrade de versão?
Depende da versão anterior e das melhorias incluídas no release. Algumas versões do Protheus trazem otimizações de desempenho — especialmente em módulos fiscais e de folha. Porém, se o gargalo atual é de infraestrutura (storage, RAM, rede), o upgrade de versão não vai resolver. Identifique primeiro a causa da lentidão.
Adicionar mais memória RAM resolve a lentidão do Protheus?
Depende da causa. Se o gargalo é RAM insuficiente no SQL Server (buffer pool sendo pressionado constantemente), adicionar RAM tem impacto imediato e positivo. Se o problema é IOPS de storage ou fragmentação de índices, a RAM adicional não terá efeito. Use o monitor de desempenho para identificar o bottleneck antes de investir em hardware.
Como saber se o problema é do storage ou da rede?
O Storage afeta todos os usuários igualmente, pois o gargalo está no servidor. A rede afeta usuários de forma proporcional à latência do link deles — usuários remotos ou de filiais são mais impactados. Se a lentidão é igual para quem está no mesmo prédio do servidor e para quem acessa remotamente, o problema provavelmente não é de rede.
O Protheus Protheus pode ter lentidão por problema no antivírus?
Sim. Antivírus com varredura em tempo real nos diretórios do AppServer, do DBAccess e dos arquivos do banco de dados do SQL Server pode causar lentidão significativa. Exclua esses diretórios da varredura em tempo real e configure o antivírus para fazer scans em horários fora do expediente.
Jobs batch do Protheus podem causar lentidão para todos os usuários?
Sim. Jobs de fechamento fiscal, cálculo de custo, folha de pagamento e integrações noturnas que rodam no mesmo servidor durante o horário comercial competem por CPU e IOPS com a operação normal dos usuários. A solução é agendar esses jobs para fora do horário de pico ou dimensionar o ambiente para suportar os dois picos simultaneamente.
Você também pode se interessar:
- Servidores: VPS vs Cloud vs Dedicados — qual escolher?
- Colocation gerenciado vs. data center próprio: qual vale mais a pena?
- Computação em Nuvem: o que é, modelos e como funciona
Saiba mais sobre hospedagem do TOTVS Protheus na nuvem da Adentro — dimensionamento correto, migração sem downtime e suporte 24×7.
