Comandos e Ferramentas para Verificar o Consumo de RAM no Linux

Monitorizar o uso de RAM em Linux significa consultar o subsistema de memória do kernel para obter métricas sobre alocação de memória física, utilização de swap e tamanhos de conjunto residente por processo. Os métodos mais diretos utilizam utilitários integrados — free, top, htop, ps, vmstat e smem — cada um expondo uma camada diferente da hierarquia de memória, desde os totais de todo o sistema até ao tamanho do conjunto proporcional (PSS) por processo.

A pressão excessiva de memória aciona o eliminador OOM (Out-of-Memory) do Linux, que termina processos à força para recuperar RAM. Compreender quais os comandos que revelam quais as métricas — e o que essas métricas realmente significam — é a diferença entre combater incêndios de forma reativa e uma gestão proativa da capacidade. Este guia abrange todas as ferramentas principais, as fontes de dados do kernel a partir das quais leem, e os casos extremos que apanham de surpresa até os administradores mais experientes.

Por Que a Monitorização de RAM É Importante em Servidores Linux

A gestão de memória do Linux é deliberadamente agressiva. O kernel utiliza toda a RAM disponível como cache de páginas para acelerar o I/O de disco, o que significa que um sistema a reportar memória livre próxima de zero não está necessariamente sob pressão — pode simplesmente estar a fazer cache de forma eficiente. Interpretar mal este comportamento é um dos erros mais comuns ao interpretar valores de memória brutos.

Principais razões para monitorizar a RAM continuamente:

• Prevenção do eliminador OOM: Identificar processos com elevado consumo de memória antes que o kernel termine serviços críticos.
• Deteção de uso de swap: Atividade intensa de swap (swapping) indica esgotamento de RAM e causa latência severa de I/O.
• Diagnóstico de fugas de memória: Processos com RSS em crescimento constante ao longo do tempo indicam fugas ao nível da aplicação.
• Planeamento de capacidade: Os dados de tendência informam decisões sobre escalonamento vertical ou redistribuição de carga de trabalho.
• Ajuste de desempenho: Ajustar vm.swappiness, huge pages e topologia NUMA requer dados de memória de base.

Num ambiente de VPS Hosting onde os recursos são partilhados ou limitados pelos limites do hipervisor, a monitorização precisa de RAM é especialmente crítica — atingir um limite de memória degrada silenciosamente o desempenho antes de qualquer alerta ser acionado.

Compreender a Terminologia de Memória do Linux

Antes de executar qualquer comando, é necessário compreender o que as colunas de saída realmente representam.

Informação crítica: Utilize sempre a coluna Available de free -h, e não a coluna Free, ao avaliar se um sistema tem RAM suficiente para uma nova carga de trabalho. A coluna Free ignora a cache recuperável, levando a falsos alarmes.

O Ficheiro /proc/meminfo: A Fonte Autoritativa

Todas as ferramentas descritas neste artigo leem de /proc/meminfo, um ficheiro virtual mantido pelo kernel em tempo real. Inspecioná-lo diretamente fornece os dados mais granulares disponíveis:

cat /proc/meminfo

Campos principais a observar:

• MemTotal — RAM utilizável total
• MemFree — RAM completamente inativa
• MemAvailable — RAM disponível estimada para novos processos
• Buffers — cache de blocos de disco brutos
• Cached — cache de páginas para ficheiros
• SwapTotal / SwapFree — capacidade e disponibilidade de swap
• Dirty — memória à espera de ser escrita no disco (valores elevados indicam pressão de I/O)
• HugePages_Total / HugePages_Free — estado de alocação de huge pages
• Slab — cache de estruturas de dados do kernel (pode crescer bastante em servidores NFS ou de bases de dados ocupados)

Compreender /proc/meminfo permite interpretar a saída de todas as outras ferramentas com contexto completo.

Verificar a RAM com o Comando free

free é a forma mais rápida de obter um instantâneo de memória de todo o sistema. Lê diretamente de /proc/meminfo e formata a saída numa tabela legível por humanos.

Utilização Básica

free

A saída é em kilobytes por defeito. Utilize flags para formatos mais legíveis:

free -h        # Human-readable (MB/GB)
free -m        # Output in megabytes
free -g        # Output in gigabytes
free -s 5      # Refresh every 5 seconds (continuous monitoring)
free -h --si   # Use SI units (1000-based) instead of binary (1024-based)

Saída de Exemplo Explicada

              total        used        free      shared  buff/cache   available
Mem:           15Gi       4.2Gi       1.1Gi       312Mi       9.8Gi       10.9Gi
Swap:         2.0Gi       128Mi       1.9Gi

Neste exemplo, o sistema parece ter apenas 1,1 GB livres, mas 10,9 GB estão realmente disponíveis para novos processos porque o kernel recuperará buff/cache a pedido. Esta é a coisa mais importante a compreender sobre a saída de free.

Caso Extremo: Uso de Swap como Sinal de Aviso

Mesmo uma pequena quantidade de uso de swap (Swap: used > 0) num servidor de produção justifica investigação. Significa que o kernel já decidiu que algumas páginas de memória são melhor armazenadas em disco do que na RAM — um sinal de que o conjunto de trabalho excede a memória física.

Verificar a RAM com o Comando top

top fornece uma visão em tempo real, continuamente atualizada, do uso de recursos do sistema, combinando estatísticas de CPU e memória com uma lista de processos ordenada.

top

Campos de Memória Principais em top

No topo da interface do top, duas linhas mostram estatísticas de memória:

MiB Mem :  16384.0 total,   1126.4 free,   4301.2 used,  10956.4 buff/cache
MiB Swap:   2048.0 total,   1920.0 free,    128.0 used.  11200.0 avail Mem

Na tabela de processos, as colunas de memória mais relevantes são:

• VIRT — tamanho da memória virtual (equivalente a VSZ)
• RES — memória física residente (RSS)
• SHR — porção de memória partilhada do RES
• %MEM — percentagem da RAM física total utilizada

Comandos Interativos Úteis do top

Executar top de Forma Não Interativa

Para scripting e captura de registos, execute top em modo batch:

top -b -n 1 | head -30

Isto produz um único instantâneo — útil para scripts de monitorização baseados em cron.

Verificar a RAM com htop

htop é um visualizador de processos melhorado, baseado em ncurses, que apresenta os mesmos dados subjacentes que top com uma interface significativamente mais utilizável. Não está instalado por defeito na maioria das distribuições.

Instalação

# Debian / Ubuntu
apt-get install htop

# RHEL / CentOS / AlmaLinux / Rocky Linux
yum install htop
# or on newer versions:
dnf install htop

# Alpine Linux
apk add htop

O Que o htop Acrescenta em Relação ao top

• Barras de memória com código de cores distinguindo memória utilizada, buffers e cache de relance
• Vista de árvore de processos horizontal e vertical (F5)
• Suporte a rato para clicar e deslocar
• Seleção múltipla para gestão de processos em massa
• Pesquisa integrada (F3) e filtro (F4) sem necessidade de memorizar atalhos de teclado
• Exibição direta da memória disponível de forma proeminente no cabeçalho

Legenda de Cores da Barra de Memória do htop

Dica profissional: No htop, prima F2 (Setup) > Display Options > ative "Show CPU frequency" e "Detailed CPU time" para uma visão mais completa juntamente com os dados de memória.

Verificar a RAM com o Comando ps

ps (process status) consulta a tabela de processos do kernel e pode ser ordenado e filtrado para identificar os maiores consumidores de memória num determinado momento.

Ordenar Processos por Consumo de Memória

ps aux --sort=-%mem

Colunas de Saída Explicadas

Comandos Práticos de Uma Linha

Mostrar os 10 processos com maior consumo de memória com saída legível por humanos:

ps aux --sort=-%mem | head -11

Mostrar o uso de memória para um nome de processo específico (por exemplo, Apache):

ps aux | grep apache2 | awk '{sum += $6} END {print sum/1024 " MB"}'

Isto soma os valores RSS de todos os processos worker do apache2 — crítico para compreender a verdadeira pegada de servidores web com múltiplos processos.

Ressalva importante: ps mostra RSS, que conta duplamente as bibliotecas partilhadas. Se 20 workers Apache mapearem a mesma biblioteca partilhada de 50 MB, ps reporta 1.000 MB de uso de biblioteca partilhada entre eles, enquanto o custo físico real é apenas 50 MB. Utilize smem para uma contabilização precisa.

Verificar a RAM com smem

smem é a ferramenta de contabilização de memória por processo mais precisa disponível no Linux porque reporta PSS (Proportional Set Size) — a memória partilhada é dividida proporcionalmente entre todos os processos que a mapeiam, eliminando o problema de dupla contagem inerente às ferramentas baseadas em RSS.

Instalação

# Ubuntu / Debian
apt-get install smem

# CentOS / RHEL 7
yum install smem

# RHEL 8+ / AlmaLinux / Rocky Linux
dnf install smem

# Alternatively, install via pip
pip install smem

Utilização Básica

smem

Opções Úteis do smem

smem -r              # Sort by RSS (descending)
smem -s pss -r       # Sort by PSS (most accurate, descending)
smem -u              # Aggregate by user
smem -m              # Show system-wide memory map
smem -p              # Show percentages instead of raw KB
smem -k              # Show values in KB
smem -t              # Show totals row
smem --pie name      # Generate a pie chart (requires matplotlib)
smem -P apache2      # Filter by process name pattern

PSS vs RSS: Por Que É Importante

Considere um servidor a executar 10 processos worker Node.js, cada um partilhando uma biblioteca de runtime V8 de 100 MB:

• RSS por processo: 200 MB (100 MB partilhados + 100 MB privados)
• RSS total reportado: 2.000 MB
• PSS por processo: 110 MB (10 MB de quota dos 100 MB + 100 MB privados)
• PSS total reportado: 1.100 MB
• RAM física real utilizada: 1.100 MB

O RSS sobrestima o uso em quase 2x neste cenário. Ao tomar decisões de escalonamento num Servidor Dedicado, utilizar PSS do smem fornece a verdade absoluta.

Verificar a RAM com vmstat

vmstat (virtual memory statistics) fornece uma visão mais ampla da memória, swap, I/O e atividade de CPU, tornando-o ideal para diagnosticar pressão de memória em todo o sistema em vez de problemas de processos individuais.

vmstat 2 10    # Report every 2 seconds, 10 times

Colunas de Memória Principais

Sinal crítico: Valores não nulos de si (swap-in) e so (swap-out) num fluxo vmstat em execução indicam swapping ativo — um sinal definitivo de esgotamento de memória. Mesmo picos ocasionais em so podem causar picos de latência de aplicação de centenas de milissegundos.

Verificar a RAM com sar (System Activity Reporter)

sar do pacote sysstat regista dados históricos de memória, permitindo análise retrospetiva — algo que as ferramentas em tempo real não conseguem fornecer.

Instalação

apt-get install sysstat    # Debian/Ubuntu
yum install sysstat        # CentOS/RHEL

Utilização

sar -r 1 5          # Memory stats every 1 second, 5 times
sar -r -f /var/log/sysstat/sa$(date +%d)   # Today's historical data
sar -S 1 5          # Swap statistics

sar é inestimável para responder a perguntas como "Houve um pico de memória às 3 da manhã que causou a falha da aplicação?" — uma pergunta que nenhuma ferramenta em tempo real consegue responder após o facto.

Verificar a RAM com /proc/<PID>/status e /proc/<PID>/smaps

Para análise aprofundada por processo, o kernel expõe mapas de memória detalhados diretamente em /proc.

Verificação Rápida de Memória por Processo

cat /proc/$(pgrep nginx | head -1)/status | grep -E "VmRSS|VmPeak|VmSize|VmSwap"

Exemplo de saída:

VmPeak:   512340 kB
VmSize:   498120 kB
VmRSS:    102400 kB
VmSwap:        0 kB

• VmPeak — tamanho máximo de memória virtual alguma vez atingido por este processo
• VmRSS — tamanho atual do conjunto residente
• VmSwap — quanto deste processo foi transferido para swap

Mapa de Memória Detalhado com smaps

cat /proc/$(pgrep mysql | head -1)/smaps | grep -E "^(Size|Rss|Pss|Shared|Private)"

Isto revela cada mapeamento de memória (heap, stack, bibliotecas partilhadas, mapeamentos anónimos) com valores individuais de RSS e PSS — a visão de memória mais granular disponível sem um profiler.

Comparação de Ferramentas: Escolher o Comando Certo

Fluxos de Trabalho Práticos de Monitorização

Fluxo de Trabalho 1: Triagem Rápida (Menos de 60 Segundos)

free -h                          # Step 1: Is Available memory critically low?
vmstat 1 5                       # Step 2: Is active swapping occurring?
ps aux --sort=-%mem | head -15   # Step 3: Which processes are the top consumers?

Fluxo de Trabalho 2: Identificar uma Fuga de Memória

# Watch a specific process's RSS grow over time
watch -n 5 'ps -o pid,rss,vsz,comm -p $(pgrep your_app)'

# Or use smem with repeated snapshots
while true; do smem -P your_app -t; sleep 30; done

Fluxo de Trabalho 3: Análise Histórica Pós-Incidente

sar -r -f /var/log/sysstat/sa$(date +%d --date='yesterday')

Fluxo de Trabalho 4: Script de Alertas Automatizados

#!/bin/bash
THRESHOLD=90
USED_PCT=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USED_PCT" -gt "$THRESHOLD" ]; then
    echo "ALERT: RAM usage at ${USED_PCT}% on $(hostname)" | mail -s "Memory Alert" admin@example.com
fi

Este script pode ser colocado num cron job para monitorização automatizada contínua — uma necessidade prática em qualquer VPS com cPanel de produção ou servidor bare-metal.

Avançado: Parâmetros de Ajuste de Memória do Kernel

Depois de identificar a pressão de memória, estes parâmetros sysctl afetam diretamente o comportamento:

# View current swappiness (default: 60)
sysctl vm.swappiness

# Reduce swap tendency (recommended for databases: 10)
sysctl -w vm.swappiness=10

# Increase dirty page write-back aggressiveness
sysctl -w vm.dirty_ratio=15
sysctl -w vm.dirty_background_ratio=5

# Drop page cache manually (use with caution on production)
sync; echo 3 > /proc/sys/vm/drop_caches

vm.swappiness explicado: Um valor de 60 significa que o kernel começará a fazer swap quando a RAM estiver 40% utilizada. Para servidores de bases de dados (MySQL, PostgreSQL, Redis), definir isto para 10 mantém os dados em RAM por muito mais tempo, reduzindo drasticamente a latência de I/O. Para sistemas de secretária ou sistemas com RAM limitada, o valor predefinido é mais adequado.

Armadilhas Comuns e Interpretações Erradas

Armadilha 1: Entrar em pânico com memória "free" baixa

Como explicado anteriormente, o Linux utiliza intencionalmente a RAM livre como cache. Um sistema com 200 MB livres mas 8 GB disponíveis está saudável. Leia sempre a coluna Available.

Armadilha 2: Somar RSS para estimar o uso total de memória

Somar os valores RSS de ps em todos os processos irá tipicamente exceder a RAM física total devido à dupla contagem de bibliotecas partilhadas. Utilize smem -t para um total preciso do sistema.

Armadilha 3: Ignorar a cache Slab

Em clientes ou servidores NFS ocupados ou servidores com muitos ficheiros pequenos, o alocador Slab do kernel pode consumir gigabytes de RAM. Verifique cat /proc/meminfo | grep Slab — esta memória é tecnicamente recuperável mas não aparece nas ferramentas ao nível do processo.

Armadilha 4: Confundir VSZ com uso real de memória

Uma aplicação Java pode mostrar 4 GB de VSZ mas apenas 512 MB de RSS. O VSZ inclui ficheiros mapeados em memória, heap reservado mas não alocado, e bibliotecas partilhadas — a maioria das quais nunca é realmente carregada na RAM física.

Armadilha 5: Ignorar a memória em cargas de trabalho contentorizadas

Dentro de um contentor Docker, free mostra a RAM total do anfitrião, não o limite cgroup do contentor. Utilize cat /sys/fs/cgroup/memory/memory.usage_in_bytes e cat /sys/fs/cgroup/memory/memory.limit_in_bytes para métricas precisas ao nível do contentor.

Configurar Monitorização Persistente de RAM

Para ambientes de produção, os comandos pontuais são insuficientes. Considere estas abordagens para visibilidade contínua:

• sysstat com cron: Permite a recolha automática de dados históricos do sar.
• Prometheus + Node Exporter: Recolhe métricas de /proc/meminfo e expõe-nas para dashboards Grafana.
• Netdata: Monitorização em tempo real de configuração zero com granularidade por segundo e deteção integrada de anomalias de memória.
• Zabbix ou Nagios: Alertas de nível empresarial com limiares de memória configuráveis e políticas de escalada.

Ao executar cargas de trabalho em infraestrutura de GPU Hosting, monitorize também a VRAM da GPU juntamente com a RAM do sistema — nvidia-smi --query-gpu=memory.used,memory.free --format=csv fornece as métricas equivalentes para a memória GPU.

Para ambientes de alojamento web geridos através de VPS Control Panels, a maioria dos painéis inclui gráficos de memória integrados — mas estes tipicamente fazem polling a intervalos de 1 a 5 minutos e não detetarão picos de curta duração que vmstat ou sar capturariam.

Matriz de Decisão Técnica: Qual Ferramenta Usar em Cada Situação

Lista de Verificação de Conclusões Principais

• Verifique sempre a memória Available do free -h, não a coluna Free, para avaliar a margem real disponível.
• Utilize vmstat 1 5 para confirmar ou descartar swapping ativo antes de escalar uma investigação.
• Utilize smem -s pss -r em vez de ps aux --sort=-%mem quando precisar de valores de memória precisos por processo — especialmente em servidores com muitos processos a partilhar bibliotecas.
• Instale sysstat em cada servidor de produção imediatamente após o aprovisionamento para ativar a recolha histórica de dados do sar.
• Defina vm.swappiness=10 de forma persistente em /etc/sysctl.conf em servidores de bases de dados para minimizar o uso de swap.
• Verifique /proc/meminfo para valores de Slab e Dirty quando as ferramentas padrão não explicam a pressão de memória observada.
• Para cargas de trabalho contentorizadas, leia os ficheiros de memória cgroup — não free — para limites e uso precisos.
• Em ambientes de alojamento partilhado ou VPS, estabeleça linhas de base de memória durante a operação normal para que as anomalias sejam imediatamente reconhecíveis.

—

Perguntas Frequentes

Qual é a diferença entre memória "free" e "available" no Linux?

"Free" é RAM sem qualquer uso atual. "Available" é a estimativa realista de memória que pode ser alocada a novos processos sem desencadear swapping — inclui cache de páginas e buffers recuperáveis. Num servidor Linux saudável, "free" está frequentemente próximo de zero enquanto "available" permanece elevado. Utilize sempre "available" para avaliações de capacidade.

Por que a soma de todos os valores RSS dos processos excede a RAM física total?

O RSS (Resident Set Size) conta a memória partilhada — como bibliotecas partilhadas — uma vez por processo que a mapeia. Se 50 processos mapearem cada um uma biblioteca partilhada de 100 MB, o total RSS soma inflaciona 4.900 MB além do custo físico real. Utilize smem com relatório PSS para eliminar esta dupla contagem.

Como encontro qual processo acionou o eliminador OOM do Linux?

Execute dmesg | grep -i "oom|killed process" ou journalctl -k | grep -i oom. O kernel regista o nome exato do processo, PID e estatísticas de memória no momento do evento de eliminação, incluindo o oom_score de todos os processos avaliados.

O que indica o uso elevado de swap e quão grave é?

O uso sustentado de swap significa que o conjunto de trabalho do sistema excede a RAM física. O kernel compensa paginando dados para o disco, que é tipicamente 100 a 1.000 vezes mais lento do que o acesso à RAM. Mesmo atividade modesta de swap causa latência de aplicação mensurável. É um sinal definitivo para reduzir o consumo de memória, aumentar a RAM ou redistribuir as cargas de trabalho.

Posso monitorizar o uso de RAM dentro de um contentor Docker usando comandos Linux padrão?

Comandos padrão como free dentro de um contentor mostram a RAM total do anfitrião, não o limite cgroup do contentor. Para métricas precisas ao nível do contentor, leia /sys/fs/cgroup/memory/memory.usage_in_bytes para o uso atual e /sys/fs/cgroup/memory/memory.limit_in_bytes para o limite configurado. Em alternativa, utilize docker stats <container_name> a partir do anfitrião para uma visão formatada.