Devora Cloud · Blog
Seu site está lento? Como descobrir se falta processador, memória ou é o código
Aprenda a ler os gráficos de CPU e memória, os reinícios e os logs (out of memory, Killed) para decidir entre adicionar réplicas, subir de plano ou corrigir o código.
Site lento é uma das reclamações mais comuns — e uma das mais caras quando a resposta é chutada. Muita gente contrata um servidor maior e descobre, uma semana depois, que o problema era uma consulta sem índice. Outros passam dias otimizando código quando a aplicação simplesmente não tinha memória suficiente.
A boa notícia: os sinais costumam ser claros quando você sabe onde olhar. Neste guia mostramos como ler CPU, memória, reinícios e logs para chegar a um diagnóstico — e quando a resposta é escalar, subir de plano ou mexer no código.
Primeiro, entenda o que os gráficos medem
No painel da Devora Cloud, os gráficos de CPU e memória mostram o percentual da cota da sua aplicação, não do servidor inteiro. Em um plano Hobby, com 0,5 vCPU e 512 MB, 100% de CPU significa que aqueles 0,5 vCPU estão ocupados; no Pro, que os 2 vCPU estão.
Olhe sempre um período longo, como as últimas 24 horas. Um pico de alguns segundos durante um deploy é normal. O que importa é o padrão: uso alto por muito tempo, crescimento contínuo ou quedas bruscas seguidas de reinício.
O painel também avisa quando CPU ou memória ficam acima de 85% por pelo menos três minutos — um bom ponto de partida para investigar.
Sinal 1: falta processador
Sintomas: a CPU fica acima de 80% por longos períodos e as páginas ficam lentas justamente nos horários de mais acesso. A memória pode estar tranquila.
O que fazer:
- No Hobby (0,5 vCPU): considere o Pro (2 vCPU) ou o Enterprise (4 vCPU).
- No Pro ou no Enterprise: ative a autoescala ou adicione uma réplica de escala, para dividir o tráfego entre cópias.
- Antes de pagar mais, confira se não há trabalho pesado sendo feito em cada requisição, como gerar relatórios, redimensionar imagens ou processar arquivos grandes.
Sinal 2: falta memória
Sintomas: a memória passa de 90%, o contador de reinícios cresce e os logs mostram mensagens como estas:
- Killed — o sistema encerrou o processo porque ele passou do limite de memória.
- out of memory ou JavaScript heap out of memory — o processo (muitas vezes Node.js) estourou o limite.
- O site cai por alguns segundos e volta sozinho, várias vezes ao dia.
Réplicas não resolvem falta de memória: cada cópia tem o mesmo limite do plano. A saída costuma ser o próximo plano (Hobby 512 MB → Pro 1 GB → Enterprise 8 GB). Se a memória sobe sem parar até o processo morrer, investigue também vazamentos: caches em memória sem limite, listas que só crescem, arquivos inteiros carregados de uma vez.
Sinal 3: o problema é o código ou o banco
Sintomas: CPU e memória estão baixas, sem reinícios, e mesmo assim as páginas demoram. Aqui, mais servidor não ajuda — a aplicação está esperando alguma coisa.
- Consultas lentas: falta de índice, consultas dentro de laços (o famoso N+1), tabelas inteiras carregadas para mostrar dez linhas.
- APIs externas lentas: pagamento, frete ou e-mail chamados durante a requisição, sem tempo limite.
- Arquivos grandes servidos pela própria aplicação em vez de URLs assinadas do S3.
- Timeouts e erros 5xx nos logs, que mostram exatamente qual rota está sofrendo.
A correção é no código: criar o índice, juntar consultas, mover tarefas pesadas para segundo plano, adicionar cache em Redis.
Tabela de diagnóstico rápido
| O que você vê | Causa provável | O que fazer |
|---|---|---|
| CPU alta por horas, memória normal | Falta processador | Autoescala ou réplica (Pro/Enterprise), ou plano com mais vCPU |
| Memória acima de 90%, reinícios, “Killed” | Falta memória | Próximo plano; procurar vazamentos |
| CPU e memória baixas, páginas lentas | Código ou banco | Índices, menos consultas, cache, tempo limite nas APIs |
| Uploads falhando com QuotaExceeded | S3 cheio | Apagar arquivos, pacote extra ou plano maior |
| Lento só para quem está longe | Distância até o servidor | Apps rodam nos EUA; no Brasil, o cache CDN da Devora acelera a entrega |
Deixe a sua IA fazer a análise
Se você usa o token de IA da Devora Cloud, não precisa fazer essa leitura sozinho. Pergunte “por que meu site está lento?” para a IA que publicou o sistema. Ela consulta as métricas de CPU e memória das últimas 24 horas, o número de reinícios de cada réplica, os logs da aplicação e o uso do S3.
A resposta vem com números, não com achismos — por exemplo, “a memória ficou acima de 90% e houve reinícios com Killed nos logs” — e com uma recomendação clara. A IA não muda o plano nem compra recursos por você: essa decisão continua no painel.
Perguntas frequentes
Adicionar réplicas resolve falta de memória?
Não. Cada réplica tem o mesmo limite de memória do plano; se o processo estoura a memória, estoura em todas as cópias. O caminho é um plano com mais RAM ou reduzir o consumo do código.
O que significa “Killed” nos logs?
Que o processo foi encerrado por usar mais memória do que o limite. Normalmente aparece junto de reinícios e de memória perto de 100% no gráfico.
CPU em 100% no painel quer dizer que o servidor está sobrecarregado?
Não necessariamente. O percentual é da cota da sua aplicação: 100% indica que ela usa toda a CPU do plano, não que a máquina inteira está cheia.
A IA pode trocar o meu plano?
Não. Ela analisa métricas e logs e recomenda. Planos, réplicas pagas e pacotes de armazenamento são contratados por você no painel.