---
title: "Como verificar CPU, RAM, disco e rede no Linux por comando"
description: "Descubra em minutos o gargalo da VPS com top, free, vmstat, df, iostat e ss: o que cada número significa e qual comando usar para cada sintoma."
url: "https://streethosting.com.br/guias/vps/verificar-cpu-ram-disco-rede-linux"
category: "vps"
slug: "verificar-cpu-ram-disco-rede-linux"
datePublished: "2026-09-28"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "iniciante"
language: "pt-BR"
keywords:
  - "verificar cpu ram disco rede linux"
  - "comandos linux uso de cpu"
  - "ver memoria ram linux free"
  - "iostat uso de disco"
  - "ss portas abertas linux"
  - "diagnostico servidor linux lento"
---

# Diagnóstico rápido no terminal: CPU, memória, disco e rede da VPS

Quando a VPS fica lenta, cada comando certo elimina uma hipótese. Veja um roteiro de um minuto e como ler load average, memória disponível, latência de disco e conexões de rede.

> **Resposta rápida**
>
> Para **verificar CPU, RAM, disco e rede no Linux** na hora, use `uptime` e `top` para carga e processos, `free -h` para memória (olhe a coluna available), `df -h` e `iostat -xz 1` para espaço e latência de disco, e `ss -tulpn` com `ip -s link` para portas, conexões e erros de rede. Seguindo essa ordem, você descobre em um minuto qual recurso está no limite.

## Roteiro de um minuto

Quando a VPS fica lenta, a tentação é abrir o htop e ficar olhando a lista mexer. Um roteiro fixo é mais rápido: cada comando elimina uma hipótese, e em um minuto você sabe se o gargalo é CPU, memória, disco ou rede. Antes, instale o pacote sysstat, que traz iostat, mpstat, pidstat e sar:

```
sudo apt install -y sysstat htop
```

1. `uptime`: load average de 1, 5 e 15 minutos. Compare com o número de vCPU mostrado por `nproc`.
2. `sudo dmesg -T | tail -20`: erros recentes do kernel, como OOM killer e falha de disco.
3. `vmstat 1 5`: fila de processos, swap em uso e espera por disco numa tela só.
4. `mpstat -P ALL 1 3`: uso de cada núcleo, incluindo iowait e steal.
5. `free -h`: memória disponível de verdade.
6. `iostat -xz 1 3`: latência e fila de cada disco.
7. `sar -n DEV 1 3`: tráfego de entrada e saída por interface.
8. `top` ou `htop`: quem está consumindo, agora que você já sabe o quê.

A ordem importa. Começar pelo top mostra o processo mais pesado, mas não diz se ele é causa ou vítima. Um banco de dados no alto da lista pode estar só esperando um disco lento, e otimizar o banco não resolveria nada.

> **Dica**
>
> Nos comandos com números no fim, como 1 5, o primeiro é o intervalo em segundos e o segundo é a quantidade de amostras. No vmstat e no iostat, a primeira linha é a média desde o boot; leia as seguintes, que mostram o que está acontecendo agora.

## CPU: uso, load average e steal

O load average que aparece no uptime traz três médias, de 1, 5 e 15 minutos, da quantidade de processos rodando ou esperando para rodar. No Linux, processos travados esperando disco também entram na conta. O número só faz sentido comparado ao total de vCPU: load 2 em uma VPS de 2 vCPU é fila cheia; em 8 vCPU, sobra folga. Se a média de 1 minuto está muito acima da de 15, o problema começou agora.

No top, a linha que começa com %Cpu(s) resume o uso do processador, e cada campo conta uma parte da história:

- **us e sy:** tempo gasto em programas e no kernel. us alto é aplicação trabalhando; sy alto de forma persistente pode ser excesso de chamadas de sistema ou de interrupções de rede.
- **wa (iowait):** CPU parada esperando o disco. Se esse número é alto, o gargalo é I/O, não processador.
- **st (steal):** tempo em que a VM quis CPU e o hipervisor não entregou. É exclusivo de máquina virtual e está explicado em [o que é CPU steal em VPS](https://streethosting.com.br/guias/vps/o-que-e-cpu-steal-vps).
- **id:** tempo ocioso. id perto de zero com us alto é CPU saturada de verdade.

Dentro do top, a tecla 1 separa os núcleos, P ordena por CPU e M por memória. A visão por núcleo é importante: um processo single thread preso em 100% de um núcleo aparece como 25% no total de uma VPS de 4 vCPU, e passa despercebido se você só olhar a média. Para confirmar fora do top:

```
mpstat -P ALL 1 3
pidstat -u 1 5
ps aux --sort=-%cpu | head -n 10
```

O mpstat repete a análise por núcleo, com as colunas %iowait e %steal separadas. O pidstat mostra quem usou CPU em cada segundo, o que pega processos curtos que somem antes de você abrir o top, como scripts do cron. Este guia é sobre a foto do momento; para acompanhar a VPS de forma contínua, com gráfico e histórico, veja [monitorar recursos com htop e Netdata](https://streethosting.com.br/guias/vps/monitorar-recursos-vps-htop-netdata).

## Memória: o que é uso de verdade

O free -h é o comando mais lido de forma errada no Linux. Um exemplo de saída numa VPS de 4 GB:

```
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.7Gi       240Mi        12Mi       1.9Gi       1.9Gi
Swap:          2.0Gi          0B       2.0Gi
```

A coluna que importa é available, não free. O Linux usa a memória sobrando como cache de disco (buff/cache) e devolve esse espaço no instante em que um programa pede. Free baixo com available alto é uma máquina saudável aproveitando a RAM. O sinal de alerta é available baixo, perto de 10% do total.

```
swapon --show
vmstat 1 5
ps aux --sort=-%mem | head -n 10
```

Swap ocupada e parada não é problema: são páginas antigas que o kernel tirou da RAM. O problema aparece nas colunas si e so do vmstat, que mostram troca com o disco por segundo. Se elas ficam diferentes de zero o tempo todo, o sistema está trocando memória com o disco agora, e tudo fica lento. A swap evita que o serviço caia num pico, mas não substitui RAM; os limites estão em [configurar swap no Ubuntu da VPS](https://streethosting.com.br/guias/vps/configurar-swap-ubuntu-vps). Na saída do ps, a coluna RSS mostra quanta memória física cada processo ocupa, em KB.

Quando a memória acaba de vez, o kernel escolhe um processo e o encerra. O serviço parece ter caído sozinho, e o log da aplicação não diz nada. A prova fica no log do kernel:

```
sudo dmesg -T | grep -i -E "out of memory|killed process"
sudo journalctl -k -b -1 | grep -i oom   # boot anterior, se a VPS reiniciou
```

## Disco: espaço e desempenho

Disco responde a duas perguntas diferentes: ainda tem espaço? E está respondendo rápido? Comece pelo espaço:

```
df -h
df -i
lsblk
```

O df -h mostra o espaço por sistema de arquivos e o df -i mostra os inodes, que são as entradas de arquivo. Um disco com espaço sobrando e inodes em 100% recusa criar arquivos do mesmo jeito, com o mesmo erro de disco cheio. Se algum dos dois passou de 85%, o próximo passo é achar o culpado, como mostra [descobrir o que ocupa espaço na VPS](https://streethosting.com.br/guias/vps/descobrir-o-que-ocupa-espaco-vps).

Agora o desempenho:

```
iostat -xz 1 3
pidstat -d 1 5
```

No iostat, procure o disco da VPS (em KVM, normalmente vda) e olhe três grupos de colunas. r_await e w_await são o tempo médio, em milissegundos, de cada leitura e escrita. `aqu-sz` é o tamanho médio da fila. %util é a fração do tempo com alguma requisição em andamento. Em NVMe, espera de poucos milissegundos é normal; dezenas de milissegundos de forma constante indicam disco saturado ou disputado. O %util perto de 100% não prova gargalo em NVMe, porque esses discos atendem muitas requisições em paralelo, então confie mais na espera e na fila.

O pidstat -d mostra quem está lendo e gravando, nas colunas kB_rd/s e kB_wr/s. Os culpados mais comuns são banco de dados sem índice fazendo varredura de tabela, backup rodando no horário de pico, log em modo debug gravando sem parar e swap ativa.

> **Dica**
>
> Para medir a latência do disco como se fosse um ping, instale o ioping e rode `ioping -c 10 /`. É uma forma rápida de comparar antes e depois de uma mudança ou de levar números concretos para o suporte.

## Rede: interfaces, portas e conexões

```
ip -br a
ip -s link show eth0
sar -n DEV 1 5
```

O ip -br a lista interfaces e endereços em formato curto. A interface pública da VPS pode se chamar eth0, ens3, ens18 ou parecido; use nos outros comandos o nome que aparecer ali. O ip -s link mostra os contadores de recebimento e envio com as colunas errors e dropped: erros crescendo apontam problema na interface, e descartes crescendo sob carga costumam indicar saturação. O sar -n DEV mostra rxkB/s e txkB/s a cada segundo. Um uplink de 1 Gbps equivale a cerca de 120 mil kB/s, então dá para ver na hora se o link está perto do limite.

```
sudo ss -tulpn
ss -s
ss -Htn state established | wc -l
```

O ss -tulpn lista as portas TCP e UDP em escuta com o processo dono (o sudo é necessário para ver o nome do processo). É a checagem definitiva para saber se o serviço está ouvindo e em qual endereço: 127.0.0.1 só aceita conexões da própria máquina, enquanto 0.0.0.0 ou [::] aceitam de fora, se o firewall deixar. O ss -s resume os contadores e a última linha conta as conexões TCP estabelecidas.

Para descobrir se poucos endereços concentram as conexões, o que ajuda a separar pico legítimo de abuso, agrupe por IP de origem:

```
ss -Htn state established | awk '{print $4}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head
```

Esses comandos olham a VPS por dentro. Para problemas entre a VPS e quem acessa, como perda de pacotes num salto do caminho, use [o MTR para diagnosticar a rota](https://streethosting.com.br/guias/infraestrutura/usar-mtr-diagnosticar-rede), e para medir a vazão real do link, veja [como testar a velocidade de rede com iperf3](https://streethosting.com.br/guias/vps/testar-velocidade-rede-vps-iperf3).

## Sintoma, comando e causa provável

Guarde esta tabela para a próxima vez que alguém disser que o servidor está lento. Ela liga o sintoma ao comando que confirma a hipótese.

| Sintoma | Comando | O que olhar | Causa provável |
| --- | --- | --- | --- |
| Tudo lento, load alto | vmstat 1 5 | Coluna r acima do número de vCPU | CPU saturada |
| Load alto com CPU ociosa | vmstat 1 5 e iostat -xz 1 | Coluna b e wa altas, await alto | Disco lento ou saturado |
| Lento sem processo pesado | mpstat -P ALL 1 | %steal acima de 5% | Disputa de CPU no host |
| Serviço caiu sozinho | sudo dmesg -T | Linha com Killed process | Falta de memória e OOM killer |
| Travadas de alguns segundos | vmstat 1 | si e so diferentes de zero | Swap em uso ativo |
| Erro No space left on device | df -h e df -i | Uso em 100% | Espaço ou inodes esgotados |
| Site não abre de fora | sudo ss -tulpn | Porta ausente ou só em 127.0.0.1 | Serviço parado ou endereço de escuta errado |
| Download lento | sar -n DEV 1 | Tráfego perto do uplink | Link saturado |
| Conexões caindo | ip -s link | errors e dropped crescendo | Interface com problema ou saturação |

## Quando o problema é falta de recurso

Todo diagnóstico termina de um de dois jeitos. Ou existe um culpado que dá para corrigir (consulta sem índice, log em debug, processo em loop, backup no horário errado), ou a carga normal simplesmente não cabe na VPS. Os sinais da segunda situação são consistentes: available abaixo de 15% no dia a dia, load acima do número de vCPU em todo horário de pico e disco acima de 80% mesmo depois de uma limpeza.

Nesse caso, otimizar mais só adia a conta. O upgrade pelo painel aumenta memória, vCPU e disco, cobra apenas a diferença proporcional do ciclo e exige um reinício da VM. Para calcular o degrau certo sem chute, use os números que você acabou de coletar com o método de [quanto de VPS o seu projeto precisa](https://streethosting.com.br/guias/vps/quanto-de-vps-preciso-para-meu-projeto).

As VPS da StreetHosting rodam em KVM com NVMe, em São Paulo, com AntiDDoS incluso. A linha Ryzen 9 9950X, com DDR5 e até 5,7 GHz, vai de R$ 39,00 por mês (1 vCPU, 2 GB, 20 GB NVMe) a R$ 814,00 (14 vCPU, 64 GB, 640 GB). A linha Xeon vai de R$ 23,00 (2 vCPU, 2 GB, 20 GB) a R$ 550,00 (24 vCPU, 64 GB, 640 GB) e entrega mais vCPU por real. Se o diagnóstico mostrou um núcleo saturado, como em servidor de jogo ou aplicação single thread, o clock da Ryzen pesa mais. Se mostrou muitos processos disputando CPU em paralelo, a quantidade de vCPU da Xeon rende mais. Compare os degraus na [página de VPS](https://streethosting.com.br/vps).

## Perguntas frequentes

### Como ver o uso de CPU no Linux?

Use top ou htop para ver o total e os processos, e mpstat -P ALL 1 para o uso de cada núcleo, com iowait e steal. Compare também o load average do comando uptime com o número de vCPU informado pelo nproc.

### Qual comando mostra a memória RAM no Linux?

O free -h. Olhe a coluna available, que é a memória que os programas ainda podem usar. A coluna free costuma ser baixa porque o Linux usa a sobra como cache de disco e devolve esse espaço assim que um programa pede.

### Como saber se o disco é o gargalo da VPS?

Rode iostat -xz 1, do pacote sysstat, e observe r_await, w_await e o tamanho da fila. Espera constante de dezenas de milissegundos, junto com iowait alto no top, indica que os processos estão parados esperando o disco.

### Como ver as portas abertas no Linux?

O comando sudo ss -tulpn lista as portas TCP e UDP em escuta com o nome do processo. Se o endereço for 127.0.0.1, a porta só aceita conexões da própria máquina; 0.0.0.0 aceita conexões de fora, desde que o firewall permita.

### O que significa load average alto?

Significa que a média de processos rodando ou esperando recurso ficou acima do número de vCPU por vários minutos. Load 4 é tranquilo em 8 vCPU e é fila em 2. No Linux, processos esperando disco também entram nessa conta.

## Guias relacionados

- [Como monitorar os recursos da VPS com htop e Netdata](https://streethosting.com.br/guias/vps/monitorar-recursos-vps-htop-netdata.md)
- [O que está ocupando espaço na VPS: como descobrir e liberar](https://streethosting.com.br/guias/vps/descobrir-o-que-ocupa-espaco-vps.md)
- [CPU steal na VPS: o que é, como medir e o que fazer](https://streethosting.com.br/guias/vps/o-que-e-cpu-steal-vps.md)
- [Como testar a latência de uma VPS a partir do Brasil](https://streethosting.com.br/guias/vps/testar-latencia-vps.md)
- [Como configurar memória swap no Ubuntu da VPS](https://streethosting.com.br/guias/vps/configurar-swap-ubuntu-vps.md)

## Produtos citados

- https://streethosting.com.br/vps
- https://streethosting.com.br/vps/ryzen

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Diagnóstico rápido no terminal: CPU, memória, disco e rede da VPS",
    "name": "Como verificar CPU, RAM, disco e rede no Linux por comando",
    "abstract": "Quando a VPS fica lenta, cada comando certo elimina uma hipótese. Veja um roteiro de um minuto e como ler load average, memória disponível, latência de disco e conexões de rede.",
    "description": "Descubra em minutos o gargalo da VPS com top, free, vmstat, df, iostat e ss: o que cada número significa e qual comando usar para cada sintoma.",
    "datePublished": "2026-09-28",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/verificar-cpu-ram-disco-rede-linux"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Como ver o uso de CPU no Linux?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Use top ou htop para ver o total e os processos, e mpstat -P ALL 1 para o uso de cada núcleo, com iowait e steal. Compare também o load average do comando uptime com o número de vCPU informado pelo nproc."
        }
      },
      {
        "@type": "Question",
        "name": "Qual comando mostra a memória RAM no Linux?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "O free -h. Olhe a coluna available, que é a memória que os programas ainda podem usar. A coluna free costuma ser baixa porque o Linux usa a sobra como cache de disco e devolve esse espaço assim que um programa pede."
        }
      },
      {
        "@type": "Question",
        "name": "Como saber se o disco é o gargalo da VPS?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Rode iostat -xz 1, do pacote sysstat, e observe r_await, w_await e o tamanho da fila. Espera constante de dezenas de milissegundos, junto com iowait alto no top, indica que os processos estão parados esperando o disco."
        }
      },
      {
        "@type": "Question",
        "name": "Como ver as portas abertas no Linux?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "O comando sudo ss -tulpn lista as portas TCP e UDP em escuta com o nome do processo. Se o endereço for 127.0.0.1, a porta só aceita conexões da própria máquina; 0.0.0.0 aceita conexões de fora, desde que o firewall permita."
        }
      },
      {
        "@type": "Question",
        "name": "O que significa load average alto?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Significa que a média de processos rodando ou esperando recurso ficou acima do número de vCPU por vários minutos. Load 4 é tranquilo em 8 vCPU e é fila em 2. No Linux, processos esperando disco também entram nessa conta."
        }
      }
    ]
  }
]
```
