vps-linux/Artigo

    VPS lenta: como diagnosticar e resolver

    Quando a VPS fica lenta, o gargalo é sempre um dos quatro recursos: CPU saturada, RAM no limite (com swap pesado), I/O de disco travando processos ou rede com latência. A ordem de diagnóstico importa — confirme CPU primeiro, depois memória, depois disco, depois rede. Cada um tem sinais distintos nos comandos de monitoramento.

    Passo 1: verificar CPU e Load Average

    CPU em 100% é o sinal mais visível. Load Average alto com CPU baixa indica I/O wait:

    bash
    # Snapshot rápido: CPU, load average, processos
    top -bn1 | head -20
    
    # Alternativa com mais detalhes
    htop
    
    # Load average: 3 valores (1min, 5min, 15min)
    # Em VPS de 2 vCPUs: load > 4 por mais de 5min = saturação
    uptime
    
    # Qual processo está consumindo CPU
    ps aux --sort=-%cpu | head -10
    
    # Consumo de CPU ao longo do tempo (1 amostra por segundo, 10x)
    pidstat -u 1 10 | head -30
    
    # Percentual de I/O wait (tempo que a CPU espera disco)
    iostat -x 1 5 | grep -E "Device|avg-cpu"
    # %iowait acima de 30% = gargalo de disco, não CPU
    Dica
    A diferença entre "CPU em 100%" e "I/O wait em 30%" é crucial: CPU alta = precisa de mais processamento; I/O wait alto = CPU fica ociosa esperando o disco, não resolve com mais CPU.

    Passo 2: verificar memória e swap

    RAM no limite força o kernel a usar swap, que é muito mais lento que a RAM:

    bash
    # Ver memória disponível e uso de swap
    free -h
    
    # Swap being heavily used = RAM insuficiente
    # "available" muito baixo = pressão de memória real
    
    # Processos que mais consomem RAM
    ps aux --sort=-%mem | head -10
    
    # Verificar se OOM killer matou processos recentemente
    sudo dmesg | grep -i "oom|killed" | tail -20
    sudo journalctl -k | grep -i "oom|killed" | tail -20
    
    # Ver se há memory leaks (processo crescendo continuamente)
    watch -n 5 'ps aux --sort=-%mem | head -5'
    
    # Uso de memória por container Docker
    docker stats --no-stream --format "table {{.Name}}	{{.MemUsage}}	{{.MemPerc}}"

    Passo 3: verificar I/O de disco

    Disco lento é silencioso — processos ficam em "D" state (uninterruptible sleep) esperando leitura/escrita:

    bash
    # Ver processos em D state (esperando I/O)
    ps aux | awk '$8 == "D" {print}'
    
    # I/O detalhado por disco
    iostat -xz 1 5
    
    # O que ler no iostat:
    # %util > 80% = disco saturado
    # await > 20ms = latência alta de I/O
    # r/s e w/s = operações de leitura e escrita por segundo
    
    # Quais processos fazem mais I/O (requer iotop)
    sudo apt install -y iotop
    sudo iotop -o   # mostra apenas processos com I/O ativo
    
    # I/O por container Docker
    docker stats --no-stream --format "table {{.Name}}	{{.BlockIO}}"
    Dica
    I/O alto em banco de dados é normal. I/O alto em containers que não deveriam gerar escrita indica log runaway (logs crescendo muito rápido) ou processo gerando arquivos temporários.

    Passo 4: verificar rede e latência

    Latência de rede afeta apps que fazem muitas chamadas externas (APIs, banco remoto, webhooks):

    bash
    # Uso de rede por interface
    nload eth0      # gráfico em tempo real (apt install nload)
    iftop -i eth0   # por conexão (apt install iftop)
    
    # Conexões de rede ativas
    ss -tunap | head -20
    
    # Conexões por estado
    ss -s
    
    # Testar latência para serviços externos
    ping -c 5 8.8.8.8          # latência para internet
    ping -c 5 IP_DO_BANCO       # latência para banco remoto
    
    # Verificar se há muitas conexões em TIME_WAIT (normal, mas pode indicar problema)
    ss -s | grep TIME-WAIT
    
    # Velocidade de upload/download (benchmark rápido)
    curl -o /dev/null https://speed.cloudflare.com/__down?bytes=100000000

    Diagnóstico de processo malicioso ou cryptominer

    VPS lenta sem causa aparente pode indicar processo malicioso (cryptominer) rodando em background:

    bash
    # Verificar processos com nome suspeito ou consumo alto de CPU sem razão
    ps aux --sort=-%cpu | head -20
    
    # Processos com conexões de rede suspeitas (portas não reconhecidas)
    ss -tunap | grep -v "ssh|docker|nginx|postgres|redis"
    
    # Verificar crontabs de todos os usuários
    sudo crontab -l -u root
    sudo crontab -l -u deploy
    sudo cat /etc/crontab
    sudo ls /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
    
    # Arquivos modificados nas últimas 24h (excluindo /proc e /sys)
    sudo find / -xdev -mtime -1 -type f 2>/dev/null \
      | grep -v -E '/proc|/sys|/tmp/.docker|/var/log' | head -30
    
    # Verificar usuários com login recente
    last | head -20
    sudo lastlog | grep -v "Never"
    Atenção
    Se encontrar processo suspeito (nome aleatório, consumindo 90%+ de CPU, com conexões para IPs desconhecidos), isole a VPS imediatamente: bloqueie o tráfego de saída com ufw default deny outgoing, documente o incidente e considere reinstalar o SO.

    $ runstack deploy --plan starter

    Não quer configurar manualmente?

    Não quer configurar manualmente? Implante o VPS em menos de 3 minutos com a Runstack. Infraestrutura da OPEN DATACENTER, com servidores no Brasil.

    Perguntas frequentes