"O site está lento" e "deu erro 500" quase sempre têm uma causa visível nos números do servidor, desde que alguém esteja olhando. Este guia explica quais métricas importam, como interpretá-las no Linux e quais limites indicam problema.
CPU e load average
O comando uptime (ou top) mostra três números de load average: a média de 1, 5 e 15 minutos de processos executando ou esperando CPU e disco.
$ uptime
14:02:11 up 32 days, load average: 3.84, 2.10, 1.75
$ nproc
4A regra prática: compare o load com o número de núcleos. Em uma máquina de 4 núcleos, um load de 3,8 está perto do limite; 8 significa que há o dobro de trabalho que a CPU consegue atender. Se o load está alto mas o uso de CPU está baixo, o gargalo costuma ser disco (veja iowait no top).
Memória: "available" é o número que importa
$ free -h
total used free shared buff/cache available
Mem: 3.8Gi 1.9Gi 210Mi 45Mi 1.7Gi 1.6Gi
Swap: 2.0Gi 120Mi 1.9GiO Linux usa memória livre como cache de disco, então free baixo é normal. Observe a coluna available. Sinais de alerta:
- available abaixo de 10% do total de forma sustentada;
- swap crescendo continuamente, o que deixa tudo lento;
- mensagens do OOM killer (
dmesg | grep -i oom) matando MySQL ou PHP-FPM.
Disco: a causa nº 1 de quedas repentinas
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 80G 76G 4.0G 95% /
# o que está ocupando espaço?
$ du -xh / --max-depth=2 2>/dev/null | sort -h | tail -15Com o disco cheio, bancos de dados param de gravar, sessões PHP falham e o servidor web responde 500. Os culpados de sempre: logs sem rotação, backups locais acumulados, caches de aplicação e imagens Docker antigas. Verifique também os inodes com df -i: milhões de arquivos pequenos podem esgotá-los mesmo com espaço livre.
Tabela de referência de limites
| Métrica | Saudável | Atenção | Crítico |
|---|---|---|---|
| Load (÷ núcleos) | < 0,7 | 0,7 – 1,0 | > 1,0 sustentado |
| Memória disponível | > 20% | 10 – 20% | < 10% ou OOM |
| Swap usado | ~0 | Crescendo | > 50% |
| Disco usado | < 75% | 75 – 90% | > 90% |
Do comando pontual ao monitoramento contínuo
Os comandos acima respondem "como está agora". Para evitar incidentes, você precisa do histórico (o disco cresce 2% por dia?) e de uma visão de todos os servidores juntos. É aqui que entra o monitoramento contínuo:
- O EzServer coleta CPU, memória, disco e carga de cada servidor periodicamente, via SSH e sem agente.
- Painel único com todos os servidores e gráficos de evolução.
- Apps para Android e iOS para conferir a saúde da infraestrutura de qualquer lugar.
- A IA Assistente explica em português a saída de comandos e sugere o próximo passo do diagnóstico.
df -h → 2) free -h → 3) uptime → 4) systemctl --failed → 5) últimos erros em journalctl -p err -n 50.