Monitorar RAM, CPU e disco em VPS Linux em tempo real
Aprenda a monitorar RAM, CPU e disco de uma VPS Linux em tempo real via terminal usando top, htop, vmstat, iostat e ferramentas auxiliares.
Quando uma VPS começa a ficar lenta, a primeira pergunta é sempre a mesma: o que está consumindo recursos. Sem dashboard gráfico, o terminal continua sendo o lugar mais rápido e preciso pra responder isso. As ferramentas certas mostram em segundos se o gargalo é CPU, memória, disco ou rede — e o que está causando.
Este tutorial é pra sysadmins e desenvolvedores que administram VPS Linux via SSH e querem dominar as ferramentas nativas de monitoramento em tempo real. Cobrimos top, htop, free, vmstat, iostat, df e du, com foco em ler os números corretamente — porque a maior parte dos erros de diagnóstico vem de interpretar mal o output, não de falta de ferramenta.
Tempo estimado de execução: 20 a 30 minutos pra rodar todos os comandos e entender a saída de cada um.
Pré-requisitos
Você precisa de uma VPS com Linux (Ubuntu 22.04 LTS, Debian 12 ou Rocky 9 servem), acesso SSH com usuário sudo e cerca de 30 MB livres pra instalar pacotes auxiliares. A maior parte das ferramentas já vem no sistema base; apenas htop, iotop e sysstat exigem instalação.
Ubuntu 22.04+ / Debian 12 / Rocky 9 SSH + sudo htop, iotop, sysstat Instalando as ferramentas auxiliares
Antes de começar, instale os pacotes que não vêm por padrão. htop é a versão interativa colorida do top, iotop mostra I/O por processo e sysstat traz iostat, pidstat e sar.
Atualize o índice de pacotes:
sudo apt updateEm sistemas Rocky/AlmaLinux substitua por sudo dnf check-update. O índice precisa estar atualizado pra instalar versões recentes.
Instale htop, iotop e sysstat:
sudo apt install -y htop iotop sysstatEm Rocky/AlmaLinux: sudo dnf install -y htop iotop sysstat. O pacote sysstat precisa ser habilitado pra coletar dados históricos: sudo systemctl enable --now sysstat.
Monitorando CPU em tempo real
CPU é o recurso mais óbvio de ler, mas o que muita gente esquece é separar uso de processo, uso de sistema (kernel) e I/O wait. Saturação por I/O wait vira lentidão sem nenhum processo aparente consumindo CPU.
Rode top pra ver o resumo geral:
topA primeira linha mostra load average de 1, 5 e 15 minutos. A terceira linha (%Cpu(s)) detalha: us (userspace), sy (kernel), id (idle), wa (I/O wait), st (steal time — tempo roubado pelo hipervisor). Pressione 1 pra ver cada vCPU separadamente, P pra ordenar por CPU, M por memória, q pra sair.
Pra uma visão mais legível e interativa, use htop:
htophtop mostra barras coloridas por vCPU, lista todos os processos com árvore de pais/filhos (F5) e permite matar processos com F9. Diferença prática: cores indicam o tipo de uso — verde é userspace, vermelho é kernel, azul é low-priority. Vermelho dominante quase sempre indica problema (driver, syscalls excessivas, contention).
Em ambientes virtualizados, a coluna st (steal time) mostra CPU que o hipervisor tirou da sua máquina pra atender outros tenants. Steal time consistentemente acima de 5% indica node oversubscrito — é hora de pedir migração ou trocar de provedor.
Monitorando memória RAM
RAM em Linux é o recurso mais mal-interpretado. O kernel usa toda a memória livre como cache pra acelerar I/O, então free baixo é estado normal. O número que importa é available, não free.
Veja o uso atual de memória:
free -hSaída típica em uma VPS de 4 GB:
total used free shared buff/cache available
Mem: 3.8Gi 1.2Gi 180Mi 50Mi 2.5Gi 2.4Gi
Swap: 2.0Gi 0B 2.0Giused 1.2 GB e available 2.4 GB significa que processos usam 1.2 GB e o kernel pode liberar mais 2.4 GB de cache sob demanda. Saúde excelente. Preocupe-se quando available cair pra menos de 10% do total ou o swap começar a crescer.
Pra acompanhar mudanças ao vivo:
watch -n 2 free -hwatch -n 2 re-executa o comando a cada 2 segundos. Útil pra observar comportamento durante um deploy, build ou carga sintética.
Pra granularidade por tempo, use vmstat:
vmstat 1A primeira linha é a média desde o boot — ignore. As subsequentes saem a cada 1 segundo. Olhe si (swap in) e so (swap out): qualquer valor consistente acima de zero indica pressão real de memória. Coluna r (processos runnable) maior que o número de vCPUs por mais de alguns segundos indica saturação de CPU.
Swap ocasional durante picos é tolerável. Swap crescente e contínuo (so > 0 sustentado) degrada performance dramaticamente porque disco é ordens de magnitude mais lento que RAM. Considere upgrade de plano ou identificar processo vazando memória.
Monitorando uso de disco
Disco tem duas dimensões: espaço ocupado (capacidade) e velocidade de I/O (throughput). Cada uma tem ferramenta dedicada.
Veja espaço ocupado por filesystem:
df -hMostra cada mount point com total, usado, disponível e percentual. Atenção a / (raiz) e /var (logs, banco de dados). Filesystem acima de 85% pede limpeza; acima de 95% é emergência — muitos serviços param de gravar pra evitar corrupção.
Pra encontrar quem está ocupando espaço, use du:
sudo du -h --max-depth=1 /var | sort -hLista cada subdiretório de /var com tamanho total, ordenado do menor pro maior. Repita descendo nos maiores. Substitua /var pelo diretório de interesse. A flag --max-depth=1 evita scan recursivo completo.
Pra I/O ao vivo, use iostat do sysstat:
iostat -xz 1-x mostra estatísticas estendidas, -z omite dispositivos com atividade zero. Métricas-chave:
%util— percentual de tempo que o disco está ocupado. Acima de 80% sustentado indica saturação.await— latência média em ms. SSD saudável fica abaixo de 10ms; HDD abaixo de 20ms.r/sew/s— operações de leitura e escrita por segundo.
Pra ver qual processo está fazendo I/O:
sudo iotop -oP-o mostra só processos com I/O ativo, -P agrupa por processo (em vez de thread). Útil pra identificar o culpado quando iostat mostra disco saturado mas você não sabe quem está martelando.
Verificação
Pra confirmar que todas as ferramentas estão funcionais, rode esta sequência num único terminal:
free -h && uptime && df -h / && iostat -c 1 2 | tail -n 5Saída esperada: três linhas de memória, uma linha de load average, uma linha de disco raiz e duas amostras de CPU. Se algum comando reclamar de “command not found”, revise a instalação do sysstat.
Pra teste mais robusto, abra htop em uma janela e em outra rode:
yes > /dev/null &Você deve ver o processo yes saturando uma vCPU em htop. Mate com kill %1 no mesmo terminal onde rodou o yes.
Resolução de problemas
iotop falha com “Could not run iotop as non-root user”
Mesmo com sudo, alguns ambientes containerizados negam acesso ao netlink taskstats. Use pidstat -d 1 do sysstat como alternativa — mostra I/O por processo sem exigir capabilities especiais.
vmstat e iostat mostram contadores estranhos na primeira linha
A primeira linha é sempre média desde o boot do sistema, não o estado atual. Ignore-a e olhe a partir da segunda. Por isso é hábito rodar vmstat 1 5 (5 amostras) e descartar a primeira mentalmente.
top mostra processo consumindo 200% de CPU
Não é bug. top reporta uso somado entre cores, então um processo multithread em máquina de 4 vCPU pode chegar a 400%. Pressione 1 pra ver cada vCPU separada e dimensionar corretamente.
kill -9 (SIGKILL) não permite que o processo limpe arquivos abertos, libere locks ou faça flush de buffers. Use sempre kill <pid> (SIGTERM) primeiro e espere alguns segundos. SIGKILL só quando SIGTERM falhar — bancos de dados e processos com escrita em disco podem corromper dados.
Próximos passos
Monitoramento em tempo real cobre o “agora”, mas problemas intermitentes exigem histórico. Algumas direções pra aprofundar:
- Configure
sar(dosysstat) pra retenção de métricas — armazena dados de CPU, memória e disco a cada 10 minutos com 30 dias de histórico por padrão. - Estude
atopem modo daemon (atop -w arquivo 60) — grava snapshots completos do sistema que você pode revisar depois comatop -r arquivo. - Aprenda a ler
/proc/pressure/{cpu,memory,io}(PSI — Pressure Stall Information), que quantifica quanto cada recurso está atrasando processos. - Pra ambientes maiores, considere um sistema de métricas com
node_exporterexportando pra Grafana — dá visualização gráfica e alertas.
Se você está colocando isso em produção, uma VPS Hostini já vem com vCPUs dedicadas (sem oversubscription agressivo) e armazenamento NVMe, o que mantém os números de %util e await saudáveis mesmo sob carga sustentada — facilitando o diagnóstico quando algo realmente sai do padrão.
Perguntas frequentes
Qual a diferença entre 'free' e 'available' no comando free -h?
'free' é a memória completamente ociosa — não está em uso por nada. 'available' é uma estimativa do que o kernel pode entregar pra novos processos sem entrar em swap, contando cache reclaimável. Em produção, olhe 'available'; 'free' baixo com 'available' alto é normal e saudável.
Por que o load average aparece maior que o número de CPUs?
Load average conta processos em estado runnable ou em I/O ininterruptível, não só CPU. Load 4.0 numa máquina de 2 vCPU pode ser 100% CPU saturada ou disco travado. Cruze com 'top' (linha %CPU vs %wa) ou 'vmstat 1' (colunas r e b) pra distinguir.
iotop pede root mesmo com sudo configurado — por quê?
iotop usa taskstats do kernel, que exige CAP_NET_ADMIN. Mesmo via sudo, alguns ambientes minimalistas (containers, alguns kernels customizados) bloqueiam. Alternativas: 'pidstat -d 1' do pacote sysstat ou ler /proc/<pid>/io diretamente.
Posso deixar htop rodando em background pra registrar histórico?
Não — htop é interativo e não loga dados. Pra histórico, use 'sar' (do sysstat), 'atop' com modo daemon (-w arquivo intervalo) ou exporte métricas via node_exporter. htop serve pra inspeção ao vivo, não pra retenção.
O cache do Linux está consumindo toda minha RAM, isso é problema?
Não. O kernel usa RAM ociosa como cache de páginas e buffers pra acelerar I/O — esse espaço é devolvido instantaneamente quando processos precisam. Preocupe-se só se 'available' (não 'free') ficar baixo e o swap começar a crescer.
Por que df -h mostra disco cheio mas du não acha os arquivos?
Provavelmente são arquivos deletados ainda abertos por processos — o inode permanece alocado até o processo fechar o descritor. Use 'lsof +L1' pra listar arquivos com link count zero e identificar o processo. Reiniciar o serviço dono libera o espaço.