Sistema lento depois de migrar para nuvem: como diagnosticar de verdade

Por que o sistema fica lento depois da migração para a nuvem

Migrar o ERP ou outros sistemas de gestão para a nuvem costuma vir com a promessa de mais estabilidade, escalabilidade e menos dor de cabeça com servidor físico. Mesmo assim, é comum que, nas primeiras semanas, os usuários reclamem: "o sistema ficou mais lento do que antes". A tela demora para abrir, o relatório trava, a emissão de nota fiscal leva o dobro do tempo. A reação natural é culpar a nuvem, mas essa conclusão quase sempre esconde a causa real.

Na prática, a lentidão após uma migração raramente tem uma única origem. Ela costuma aparecer na soma de fatores que antes ficavam escondidos pela rede local: aplicações que foram desenvolvidas para conversar com o banco de dados na mesma sala, links de internet dimensionados para navegação e e-mail, DNS mal configurado, máquinas virtuais com disco ou memória subdimensionados. Quando o servidor estava a um cabo de distância, a latência era praticamente zero. Com o servidor a dezenas ou centenas de quilômetros, cada ida e volta de pacote passa a pesar.

Por isso, a primeira regra do diagnóstico é simples: não trocar peças no escuro. Aumentar a banda, dobrar a memória da VM ou mudar de provedor sem medir antes é caro e muitas vezes não resolve. O caminho certo é isolar camada por camada, com dados, até encontrar o gargalo verdadeiro.

Passo 1: delimitar o problema antes de medir qualquer coisa

Antes de abrir qualquer ferramenta, vale responder algumas perguntas que economizam horas de investigação. A lentidão afeta todos os usuários ou só uma filial? Acontece o dia inteiro ou em horários específicos, como no fechamento do mês ou no início do expediente? Atinge todas as telas do sistema ou apenas algumas rotinas, como relatórios e consultas pesadas? Usuários em home office sentem o mesmo que quem está no escritório?

Essas respostas já apontam direções diferentes. Se só uma filial reclama, o problema tende a estar no link ou na rede local daquela unidade. Se todos sentem lentidão apenas em horário de pico, o suspeito passa a ser capacidade: CPU, disco, conexões simultâneas no banco ou banda saturada. Se apenas uma rotina está lenta, o foco é a aplicação ou uma consulta específica no banco de dados.

• Escopo: quantos usuários, quais locais, quais módulos do sistema.
• Padrão de tempo: constante, intermitente ou concentrado em horários de pico.
• Comparação: tempo da mesma operação antes e depois da migração, se houver registro.
• Mudanças recentes: atualização do ERP, novo antivírus, troca de firewall, alteração de VPN.

Registrar essas informações de forma objetiva, com exemplos concretos ("emissão de NF-e leva 40 segundos, antes levava 8"), transforma uma reclamação genérica em um problema mensurável.

Passo 2: link, latência e DNS — a camada mais subestimada

Em boa parte dos casos de ERP lento na nuvem, o culpado está no caminho entre o usuário e o servidor. E aqui há uma confusão frequente: banda não é o mesmo que latência. Um link de 500 Mbps com latência de 80 ms pode entregar uma experiência pior do que um link de 100 Mbps com 10 ms, especialmente em sistemas que fazem centenas de pequenas consultas por operação. Sistemas cliente-servidor tradicionais, que conectam direto no banco de dados, são os mais sensíveis a isso.

Para diagnosticar essa camada, meça de forma contínua e não apenas uma vez. Um teste de velocidade isolado diz pouco; o que importa é o comportamento ao longo do dia. Ferramentas como ping contínuo, traceroute e MTR ajudam a identificar perda de pacotes, variação de latência (jitter) e saltos problemáticos no caminho. Se a VPN entre escritório e nuvem estiver envolvida, verifique também o MTU: fragmentação de pacotes em túneis IPsec é uma causa clássica de lentidão intermitente e difícil de explicar.

1. Meça a latência do escritório até o servidor em nuvem em diferentes horários.
2. Verifique perda de pacotes e jitter, não apenas a média.
3. Confirme se o tráfego do ERP está passando pelo link correto (e não por um link de backup mais lento).
4. Teste resolução de nomes: um DNS que demora 2 a 3 segundos para responder, ou que aponta primeiro para um endereço inexistente, pode adicionar atraso em cada conexão.
5. Avalie se o firewall ou o proxy está inspecionando o tráfego do ERP de forma desnecessária.

Se o sistema é rápido quando acessado de dentro da própria nuvem (por exemplo, via área de trabalho remota no servidor) e lento a partir do escritório, o problema está no caminho, não no servidor.

Esse teste simples de comparação é um dos mais valiosos do diagnóstico: ele separa em poucos minutos a camada de rede da camada de infraestrutura e aplicação.

Passo 3: disco, memória e CPU da infraestrutura em nuvem

Se o sistema continua lento mesmo quando acessado de dentro da nuvem, o foco passa para os recursos da máquina virtual. E aqui o principal vilão costuma ser o disco. Muitos ambientes são migrados para discos de desempenho padrão, com limite de IOPS e throughput bem abaixo do que o servidor físico antigo com SSD entregava. Banco de dados é extremamente sensível a latência de disco: se cada leitura ou escrita demora dezenas de milissegundos, o ERP inteiro sente.

No Windows Server, o Monitor de Desempenho (Perfmon) permite acompanhar contadores como latência média de leitura e escrita por disco, tamanho de fila, uso de CPU por processo e memória disponível. No Linux, ferramentas como iostat, vmstat e top cumprem o mesmo papel. Como referência prática, latências de disco consistentemente acima de 20 ms em um servidor de banco de dados já merecem atenção; acima de 50 ms, são quase certamente parte do problema.

• Disco: latência de leitura/escrita, fila, limite de IOPS do tipo de disco contratado.
• Memória: uso de paginação (swap/pagefile), memória disponível para o banco de dados.
• CPU: uso sustentado acima de 80%, e também o "CPU ready" ou "steal time", que indica disputa por processador no host.
• Rede interna: se aplicação e banco estão em VMs separadas, a latência entre elas também conta.

Outro ponto que merece atenção é o antivírus. Varredura em tempo real sobre arquivos de banco de dados, logs de transação e pastas do ERP pode derrubar o desempenho de forma drástica. Exclusões bem configuradas, seguindo a recomendação do fabricante do sistema, costumam trazer ganho imediato.

Passo 4: banco de dados e aplicação — onde a lentidão realmente mora

Quando rede e infraestrutura estão saudáveis, a investigação chega ao banco de dados e à aplicação. É comum que problemas latentes apareçam justamente após a migração: estatísticas desatualizadas, índices fragmentados, planos de execução que mudaram com a nova versão do servidor de banco, ou consultas que sempre foram ineficientes mas eram "compensadas" por hardware local rápido.

Em ambientes com SQL Server, por exemplo, vale analisar as consultas que mais consomem tempo, as esperas predominantes (wait stats) e eventuais bloqueios entre sessões. Se o tipo de espera mais frequente é relacionado a I/O, o problema volta para o disco. Se é relacionado a rede entre cliente e servidor, reforça a hipótese de latência. Se há muitos bloqueios, a causa pode ser uma rotina específica, como um relatório pesado rodando no meio do expediente.

Também é importante verificar a arquitetura de acesso ao sistema. ERPs cliente-servidor, em que o programa instalado na estação conversa direto com o banco, raramente se comportam bem com latências acima de 20 a 30 ms. Nesses casos, a solução mais eficaz não é aumentar recursos, e sim mudar o modelo de acesso: publicar o sistema via área de trabalho remota (RDS) ou aplicativo remoto, de forma que aplicação e banco fiquem lado a lado na nuvem e só a tela trafegue até o usuário.

Nuvem não corrige arquitetura inadequada. Um sistema projetado para rede local precisa de um modelo de acesso pensado para a distância.

Como a Duk ajuda a resolver lentidão na nuvem

Diagnosticar lentidão depois de uma migração exige método e visão de ponta a ponta: link, firewall, VPN, DNS, virtualização, disco, banco de dados e o próprio sistema de gestão. Quando cada parte é tratada por um fornecedor diferente, é comum que todos digam que "do lado deles está tudo certo" enquanto o usuário continua esperando a tela carregar. Ter um parceiro que enxerga o ambiente inteiro faz toda a diferença.

A Duk Informática & Cloud atua há mais de 18 anos com infraestrutura, cloud e suporte de TI para empresas, com mais de 550 clientes atendidos e reconhecimento como Microsoft Gold Partner. Nosso time conduz o diagnóstico com medições reais, identifica o gargalo verdadeiro e propõe o ajuste certo, seja reconfigurar a VPN, redimensionar discos, otimizar o banco de dados ou mudar o modelo de acesso ao ERP. Com data center próprio em Alphaville e suporte com SLA, também conseguimos hospedar sistemas críticos com a proximidade e o desempenho que a operação exige.

Se o seu sistema ficou lento depois de migrar para a nuvem, ou se você está planejando uma migração e quer evitar esse problema desde o início, fale com a Duk. Um diagnóstico bem feito costuma custar muito menos do que meses de produtividade perdida.