Guia Completo de Monitoramento Linux com vmstat, iostat e sar

Parte 1: A Importância da “Santíssima Trindade” da Observabilidade

Administrar sistemas Linux em ambientes de produção corporativos, seja em servidores físicos tradicionais (bare-metal) ou em infraestruturas elásticas de computação em nuvem (como AWS, Google Cloud e Microsoft Azure), exige um conhecimento extremamente profundo de como os recursos de hardware estão sendo utilizados pelos processos de software rodando em espaço de usuário.

Quando um servidor apresenta alertas de lentidão, a reação instintiva e primária de muitos administradores de sistemas ou desenvolvedores júnior é verificar comandos básicos como top ou htop. Embora essas ferramentas sejam excelentes e indispensáveis para uma visão geral, visual e imediata dos processos que mais consomem CPU ou RAM em um dado segundo, elas frequentemente falham em fornecer a granularidade, o histórico ou o contexto técnico de baixo nível necessário para diagnosticar gargalos complexos. Estamos falando de problemas obscuros como latência de I/O em discos, paginação agressiva de memória ou micro-explosões de tráfego de rede.

É exatamente aqui que entra a verdadeira “santíssima trindade” da análise de performance em modo texto do sistema operacional Linux: vmstat, iostat e sar.

O domínio conjunto sobre o vmstat, iostat e sar é o que separa os usuários casuais de Linux dos verdadeiros Engenheiros de Confiabilidade de Sistemas (SREs). Estas três ferramentas clássicas oferecem uma visão cirúrgica e irrefutável do comportamento do kernel. Onde painéis gráficos falham por perda de pacotes ou agregação de dados (downsampling), as métricas brutas fornecidas por vmstat, iostat e sar são a fonte da verdade para identificar a causa raiz de qualquer anomalia de performance. Neste artigo com mais de 2000 palavras, vamos mergulhar na prática de cada uma dessas ferramentas.

Monitorar o servidor é essencial, mas o verdadeiro ganho vem da otimização. Para isso, veja o guia completo de performance de servidores Linux.

Para aprofundar a análise, veja também:

• como usar vmstat
• como interpretar load average
• como identificar CPU 100%
• como analisar iowait

Parte 2: O Pacote sysstat e a Coleta de Dados Base

Antes de começarmos a analisar a linha de comando do vmstat, iostat e sar individualmente, é estritamente necessário entender a arquitetura de onde essas ferramentas retiram seus dados. O comando vmstat geralmente vem instalado de fábrica dentro do pacote procps na vasta maioria das distribuições Linux. No entanto, o iostat e o sar fazem parte de um pacote de software à parte, de suma importância, chamado sysstat.

O sysstat não é apenas um agrupamento de comandos para visualização de terminal em tempo real; sua maior e mais formidável força reside na sua capacidade nativa de coletar e registrar em disco dados históricos de performance do sistema em segundo plano. O sar, em particular, depende totalmente da arquitetura de coleta do sysstat.

Ferramentas como vmstat, iostat e sar ajudam a coletar dados, mas a melhoria depende de uma análise completa. Confira a otimização de servidores Linux.

Instalação e Habilitação do sysstat

Se você estiver operando um ecossistema baseado em Debian ou Ubuntu Server:

sudo apt update
sudo apt install sysstat

sudo apt update
sudo apt install sysstat

Em ambientes corporativos baseados em Red Hat Enterprise Linux (RHEL), CentOS, AlmaLinux ou Rocky Linux:

sudo yum install sysstat
# ou utilizando o DNF nas versões mais recentes
sudo dnf install sysstat

sudo yum install sysstat
# ou utilizando o DNF nas versões mais recentes
sudo dnf install sysstat

Configuração Crítica: Após a instalação em sistemas Debian/Ubuntu, a coleta histórica (que é o motor do sar) é instalada com status desativado por padrão para economizar espaço em disco e ciclos de CPU. Para ativar esse motor de telemetria, você deve editar o arquivo de configuração /etc/default/sysstat e modificar a variável ENABLED="false" para ENABLED="true". Em seguida, é imperativo reiniciar e habilitar o serviço no systemd:

sudo systemctl enable --now sysstat
sudo systemctl restart sysstat

sudo systemctl enable --now sysstat
sudo systemctl restart sysstat

Com o motor ativado, o utilitário sadc (System Activity Data Collector) passará a gravar informações em arquivos binários dentro do diretório /var/log/sysstat/ ou /var/log/sa/ a cada 10 minutos (padrão configurado via Cron ou Systemd Timers).

Em sistemas Alamlinux/Rock Linux execute:

sudo systemctl enable --now sysstat-collect.timer
sudo systemctl enable --now sysstat-summary.timer

sudo systemctl enable --now sysstat-collect.timer
sudo systemctl enable --now sysstat-summary.timer

sysstat-collect.timer: Coleta dados a cada 10 minutos e salva em /var/log/sa/saDD.
sysstat-summary.timer: Gera um resumo diário (relatório) às 23:59.

Parte 3: Mergulho Profundo no vmstat – Mais do que Apenas Memória

Apesar do nome derivar de “Virtual Memory Statistics”, reduzir o vmstat a uma ferramenta de memória é um erro crasso. Ele atua, na verdade, como um painel de instrumentos abrangente e rápido para o estado geral de integridade do sistema operacional. Ele reporta de forma concisa informações sobre o estado de processos na fila de execução, alocação de memória RAM, paginação (swap), I/O de dispositivos de blocos, interrupções de hardware e níveis de atividade da CPU.

O charme principal do vmstat comparado a outras ferramentas do trio vmstat, iostat e sar, é seu impacto de performance virtualmente nulo e a sua formatação tabular perfeita para leitura humana rápida.

Executando o vmstat na Prática

A sintaxe clássica do vmstat exige dois argumentos numéricos: o delay (quantos segundos esperar entre cada coleta) e o count (quantas linhas gerar antes de encerrar o comando). Vamos rodar o comando vmstat 1 5:

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0   1024 120456  45612 876324    0    0    12    45   56  120 15  5 78  2  0
 1  0   1024 119800  45612 876324    0    0     0   120   80  150 20  4 75  1  0
 4  1   1024 118000  45612 876324    0    0  4096     0 1200 2100 45 15 10 30  0
 1  0   1024 117500  45612 876324    0    0     0    10  100  200 10  2 88  0  0
 0  0   1024 117500  45612 876324    0    0     0     0   40   90  1  1 98  0  0

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0   1024 120456  45612 876324    0    0    12    45   56  120 15  5 78  2  0
 1  0   1024 119800  45612 876324    0    0     0   120   80  150 20  4 75  1  0
 4  1   1024 118000  45612 876324    0    0  4096     0 1200 2100 45 15 10 30  0
 1  0   1024 117500  45612 876324    0    0     0    10  100  200 10  2 88  0  0
 0  0   1024 117500  45612 876324    0    0     0     0   40   90  1  1 98  0  0

Dica de Ouro: A primeira linha impressa não reflete o exato momento atual. Ela sempre apresenta as médias de todos os valores métricos desde o último boot do sistema. As linhas seguintes é que fornecem o delta preciso durante o intervalo estipulado de um segundo.

Análise Detalhada das Métricas do vmstat

Para utilizar todo o potencial do conjunto vmstat, iostat e sar, a interpretação milimétrica dessas colunas é obrigatória.

A Fila de Processos (Procs)

• r (Runnable): Representa a quantidade de processos (ou threads) que estão na fila prontos para rodar, mas que estão aguardando tempo de alocação de CPU pelo escalonador (scheduler). Se o valor de r for consistentemente superior ao número total de núcleos de CPU lógicos do seu servidor, você encontrou um claro gargalo de processamento. A CPU simplesmente não dá conta da demanda.
• b (Blocked): O número de processos bloqueados em estado “uninterruptible sleep”. Normalmente, isso significa que esses processos estão travados aguardando uma resposta física de um dispositivo de bloco (como um disco extremamente lento) ou de um sistema de arquivos de rede (NFS).

Memória Virtual e Física

• swpd: Memória virtual atualmente em uso. Se for diferente de zero, parte da sua RAM foi descarregada no disco físico.
• free, buff e cache: O Linux utiliza a filosofia de que “memória RAM livre é memória desperdiçada”. Portanto, a coluna free quase sempre será baixa. O kernel usa toda a sobra de RAM para fazer cache do disco (cache) e criar buffers de leitura/gravação (buff), o que acelera incrivelmente o sistema. Se um aplicativo pedir mais RAM, o Linux descarta esse cache instantaneamente.

O Perigo da Paginação (Swap)

• si (Swap In) e so (Swap Out): Taxa de entrada e saída de dados entre o disco de swap e a memória RAM. Se, durante a sua análise, as colunas si e so estiverem reportando milhares de kilobytes sendo movidos constantemente, você está presenciando o temido Thrashing. A performance da máquina vai a zero porque a CPU gasta mais tempo movendo pedaços de memória para lá e para cá do que de fato processando transações.

Desempenho da CPU

• us (User Time): Ciclos gastos rodando aplicações normais (bancos de dados, web servers, seu código Python/Java/Node).
• sy (System Time): Tempo processando rotinas do kernel. Valores acima de 30% em sy podem indicar uma falha grave na aplicação fazendo excessivas chamadas de sistema (syscalls).
• wa (I/O Wait): Se este valor subir, significa que a CPU não tem nada para fazer, porém existe um processo necessitando que o disco termine de ler/gravar. Se o wa está em 80%, o seu disco é a âncora do seu servidor.
• st (Steal Time): Fundamental na computação em nuvem. É o percentual de tempo em que sua máquina virtual exigiu processamento, mas o Hypervisor (o host físico) não entregou porque estava sobrecarregado atendendo a outras instâncias de outros clientes. É o fenômeno do noisy neighbor (vizinho barulhento).

Parte 4: O Raio-X Físico com iostat

Enquanto o vmstat aponta os sintomas, o iostat entrega o diagnóstico de hardware. Dentre o ecossistema vmstat, iostat e sar, o iostat é a única ferramenta com foco absoluto e irrestrito na análise de estresse dos barramentos de armazenamento físico. Quando o vmstat mostra valores altos nas colunas wa e b, o comando iostat vai responder a duas perguntas vitais: Qual disco, partição ou volume lógico exato está causando o trauma, e quão severa é a degradação de performance?

Parâmetros Estendidos do iostat

Executar o comando puro é ineficaz para diagnósticos ao vivo. O poder irrefutável reside no uso da flag estendida -x. Vamos adicionar a flag -z para ocultar dispositivos inativos e analisar o output a cada dois segundos:

$ iostat -xz 2
Linux 5.15.0-aws (servidor-db-01)   11/04/2023  _x86_64_    (8 CPU)
Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
nvme1n1        250.00 4500.00   1000.00  35000.00     0.00   100.00   0.00   2.00    1.50   18.80  10.50     4.00     7.70   0.20  98.00
sda              0.00    2.00      0.00      8.00     0.00     0.00   0.00   0.00    0.00    2.00   0.01     0.00     4.00   1.00   0.20

$ iostat -xz 2
Linux 5.15.0-aws (servidor-db-01)   11/04/2023  _x86_64_    (8 CPU)
Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
nvme1n1        250.00 4500.00   1000.00  35000.00     0.00   100.00   0.00   2.00    1.50   18.80  10.50     4.00     7.70   0.20  98.00
sda              0.00    2.00      0.00      8.00     0.00     0.00   0.00   0.00    0.00    2.00   0.01     0.00     4.00   1.00   0.20

Decifrando os Códigos do Hardware

Entender os meandros do iostat é o ápice do troubleshooting de infraestrutura.

• IOPS (r/s e w/s): Estas colunas indicam Operações de Leitura/Gravação por Segundo. O limite depende puramente do hardware. Discos magnéticos antigos de 7200 RPM suportam cerca de 150 IOPS. Já um drive NVMe PCIe 4.0 pode entregar mais de 500.000 IOPS. Acompanhar isso é vital para não estourar a cota de provedores como AWS EBS.
• Throughput (rkB/s e wkB/s): É a vazão de dados em Kilobytes. Enquanto IOPS mede “quantidade de pacotes”, o throughput mede o “peso”. Sistemas de streaming de vídeo geram enorme Throughput com baixos IOPS, enquanto Bancos de Dados geram massivos IOPS de pequeníssimo Throughput.
• Latência (r_await e w_await): Esta é a métrica mais crítica de todo o iostat. É o tempo médio de espera, medido em milissegundos (ms), para que as operações sejam totalmente concluídas (englobando tanto o tempo na fila do Linux quanto o tempo do hardware físico atuando). Se você possui um banco de dados relacional e seu w_await ultrapassa a barreira dos 10ms a 15ms em discos de estado sólido (SSD), o sistema começará a experimentar problemas de lentidão perceptível no front-end.
• A Pegadinha da Utilização (%util): Em discos magnéticos mecânicos (HDDs), quando o %util chegava a 100%, o disco estava “saturado”. Contudo, na era dos Arrays RAID modernos e das memórias Flash (NVMe), um dispositivo pode facilmente registrar 100% de utilização e não estar esgotado. Isso ocorre porque controladores modernos conseguem lidar com múltiplas transações simultaneamente e de forma paralela. Logo, o uso exclusivo do %util para declarar falha é um erro amador. Combine-o sempre com o crescimento da fila de tarefas (aqu-sz) e as latências (await).

Parte 5: Viagem no Tempo com o sar

Tanto o vmstat quanto o iostat são brilhantes, formidáveis e precisos para o agora. Mas a dura realidade de um Administrador de Sistemas raramente é tão conveniente. Quase sempre, o alerta PagerDuty soa no meio da noite, ou o gestor reporta na segunda-feira pela manhã que “o e-commerce travou no domingo à tarde”. Entrar na máquina 15 horas após a ocorrência e rodar vmstat produzirá dados de um sistema calmo e ocioso.

O coração pulsante de longo prazo da tríade vmstat, iostat e sar é, inegavelmente, o utilitário sar (System Activity Reporter).

Como mencionado na introdução sobre o pacote sysstat, os arquivos de log binários criados pelo sadc (como sa05 para o dia 5 do mês) são a matéria-prima do sar.

Extraindo Dados do Passado

O uso mais primário do sar se dá pelo interrogatório de arquivos antigos utilizando a flag -f. Suponha que o servidor falhou ontem (dia 14 do mês) às 15:00.

# Inspecionando o arquivo de log do dia 14
sar -f /var/log/sysstat/sa14 -s 14:00:00 -e 16:00:00

# Inspecionando o arquivo de log do dia 14
sar -f /var/log/sysstat/sa14 -s 14:00:00 -e 16:00:00

Com as flags de start (-s) e end (-e), limitamos o escopo de análise à janela crítica de incidente.

Monitorando Subsistemas Específicos

O sar é o canivete suíço definitivo. Ele permite isolar e monitorar qualquer componente da arquitetura Linux:

1. Investigação de CPU (sar -u e sar -P ALL): Reporta o mesmo formato da coluna CPU do vmstat. A vantagem de usar o -P ALL é que ele descreve o comportamento de cada núcleo individualmente. Uma falha clássica de aplicações single-threaded (como servidores Redis mal configurados ou scripts Python bloqueantes) é travar 100% de apenas um núcleo (Core 0), deixando os outros 15 núcleos ociosos. Apenas a visão por núcleo revela isso.
2. Investigação de Memória e OOM Killer (sar -r): Mostra a evolução histórica da alocação da RAM. A métrica kbcommit (%commit) é ouro puro. Ela mostra a quantidade teórica de memória garantida às aplicações pelo kernel. Se esse número atinge quase 100%, você tem a certeza matemática de que o temido OOM Killer (Out-Of-Memory Killer) do Linux entrou em ação e expurgou do sistema processos vitais à força para não sofrer um kernel panic.
3. Análise Histórica de Paginação (sar -W): Corresponde às métricas si/so do vmstat. Se você rodar o sar -W -f para a hora da lentidão e enxergar a coluna pswpin/s na casa dos milhares, você provou categoricamente que a lentidão foi causada por falta de RAM disponível, forçando uso do disco, e não por falha de processador.
4. Auditoria Histórica de Discos (sar -d): A união entre a capacidade de disco e histórico é feita aqui. Recomendamos o uso extremo da flag sar -dp (onde ‘p’ traduz os números feios de major/minor do kernel dev8-0 em nomes amigáveis como sda, sdb). Este comando vai trazer basicamente o relatório do iostat retroativamente, informando latências e blocos por segundo no momento exato do problema de ontem.
5. Gargalos Ocultos de Rede (sar -n DEV e sar -n TCP): Uma lacuna que o vmstat e o iostat não cobrem é a camada de comunicação em rede. O sar reporta precisamente métricas de tráfego. sar -n DEV informa o volume de pacotes transmitidos (Tx) e recebidos (Rx) por segundo, assim como o consumo de banda real em kilobytes de cada interface física (eth0, ens5). Se a sua placa de rede suporta até 1 Gbit/s e a métrica txkB/s registrada atingiu constantemente o limiar de 120.000 KB/s no instante em que as reclamações de “banco de dados inatingível” se multiplicaram, você acabou de culpar a saturação do cabo ou porta de switch, e não do software do banco de dados em si.

Identificar gargalos é apenas o primeiro passo. Veja a estratégia completa de otimização de servidores Linux.

Parte 6: Cenários Práticos Integrados de Resolução (Troubleshooting)

Dominar os manuais das funções é apenas a base; a verdadeira proficiência na união de ferramentas como o vmstat, iostat e sar consolida-se durante crises severas. Vamos simular duas investigações completas baseadas em cenários frequentes do mundo corporativo.

Estudo de Caso 1: A Tempestade do Banco de Dados Relacional

Sintoma: Os desenvolvedores informam que o microserviço de check-out do carrinho de compras começou a apresentar eventos de timeout (tempo de limite excedido) aleatórios durante toda a última noite.

Investigação com as ferramentas:

1. O SRE conecta-se por SSH ao servidor mestre PostgreSQL que processa os pagamentos.
2. Para observar o presente, ele lança vmstat 1 5. O servidor parece normal (0 processos na fila r, 90% de id idle CPU). O evento não está acontecendo mais.
3. O SRE apela para a memória de longo prazo: roda o sar -q -f /var/log/sa/sa20 para verificar a carga das filas (load average e tarefas rodando) durante a madrugada.
4. Observa-se que entre 02:00 e 04:00, a fila de bloqueio e carga do sistema cresceu desproporcionalmente.
5. Partindo para o hardware, utiliza-se sar -dp -f /var/log/sa/sa20. Os registros revelam o criminoso. O dispositivo nvme1n1, onde os logs do tipo WAL (Write-Ahead Log) do banco residem, estava sendo massacrado com requisições batendo latências (await) que chegaram a terríveis 300 milissegundos entre as 02h e as 04h.
6. Para descartar problemas do próprio disco e focar no que o sistema emitiu, cruza-se isso com atividades da rede interna: sar -n DEV. Há um gigantesco spike (pico) de tráfego de entrada na interface de rede às 02:00.

Veredito e Solução: Não foi falha de disco, de CPU ou do banco em si. Alguém agendou um processo em lote massivo e não otimizado para despejar milhões de novos registros simultâneos no banco na madrugada (o grande tráfego de rede RX comprova). O disco de log, projetado para suportar apenas fluxo transacional normal, atingiu sua taxa máxima de IOPS tentando processar o commit seguro dessas inserções brutas. A solução de engenharia foi forçar a aplicação agendada a injetar linhas em blocos maiores e compassados, e migrar a partição de logs (WAL) para um modelo de armazenamento cloud de mais alta performance de IOPS provisionados (como volumes io2 na AWS).

Estudo de Caso 2: A Aplicação “Zumbi” que devora recursos

Sintoma: Um nó (node) do cluster Kubernetes de produção para de responder completamente ao health check às 15:30. Quando os administradores conseguem logar na máquina às 15:50, tudo está perfeito e calmo.

Investigação com as ferramentas:

1. Como o problema não ocorre mais, os comandos de tempo real vmstat e iostat são descartados da fase inicial. O SRE abre o sar.
2. Começando pela telemetria global da CPU: sar -u. Verifica-se que, por volta das 15:15, a coluna %system (sy no vmstat) começou a subir exponencialmente até bater 60%. Logo depois, às 15:25, a CPU disparou para 100% no %iowait. A máquina congelou esperando I/O.
3. Surpreendentemente, ao checar os discos com sar -dp, nenhum disco apresentava tráfego anômalo de leitura/gravação de aplicações (arquivos normais).
4. O SRE aciona o monitoramento de memória e paginação histórica: sar -r e sar -W. Aqui estava a prova definitiva.
5. Às 15:10, o %memused estava em 99%. E, nos instantes que antecederam o travamento total relatado das 15:25, o sar -W mostrou a coluna pswpout/s (páginas forçadas para dentro do disco de Swap) reportando dezenas de milhares de operações por segundo.

Veredito e Solução: O servidor não teve um problema de I/O puro ou pico de processamento real. Uma aplicação mal construída (ou com um memory leak flagrante) em um contêiner esgotou vorazmente os 64GB de memória RAM física do nó. Sem memória, o kernel do Linux, em desespero, começou a transferir a área de memória ativa para um frágil arquivo de partição de SWAP hospedado no disco raiz (/). O limite de gravação de arquivos minúsculos arruinou os tempos de resposta do disco de sistema, o que causou o %iowait estratosférico e congelou a rede, fazendo o nó falhar os testes de conexão (Health Checks). Minutos depois, o sistema ativou o oom-killer, assassinou a aplicação causadora, a memória foi esvaziada e o sistema pareceu perfeitamente normal às 15:50. Solução: Impor limites de memória física rigorosos (Cgroups/Memory Limits) nos pods do Kubernetes, prevenindo que uma falha isolada drene as capacidades essenciais de Swap e trave o sistema operacional host daquela máquina de produção.

Conclusão: Observabilidade no Nível do Kernel

Embora estejamos plenamente imersos em uma era dourada de interfaces ricas, dashboards belíssimos e stacks de observabilidade de alta complexidade contendo Prometheus, Grafana, Zabbix, DataDog, New Relic e outros, depender de forma míope e exclusiva das comodidades modernas pode mascarar riscos estruturais em infraestruturas cruciais.

As ferramentas de raiz de linha de comando baseadas no ecossistema Unix, notavelmente o vmstat, iostat e sar, interagem em baixíssimo nível, se interfaceando diretamente com os contadores de performance binários gerados pelo próprio núcleo do kernel no diretório virtual /proc. Elas são leves como plumas, não dependem de conexão com a internet externa para funcionarem e não perdem granularidade visual mesmo frente à catástrofes extremas de esgotamento de máquina.

Ao integrar o domínio completo dos comandos listados na sua rotina diária de administração de sistemas ou fluxo de SRE, você afia de forma formidável a sua capacidade técnica analítica. Você deixa de deduzir problemas usando gráficos vagos e passa a provar, baseando-se em contadores físicos do sistema operacional, os limites exatos do silício, da memória volátil e do armazenamento persistente nos seus parques de servidores de alta escalabilidade.

Para transformar monitoramento em resultados reais, consulte o guia de como otimizar servidores Linux.

FAQ

Veja Mais:

Performance de Servidores Linux: Guia Completo 2026
Servidor Lento: Como Identificar o Gargalo
I/O de disco servidor Linux: Como Resolver Gargalos
CPU 100% no Linux: O Que Verificar Primeiro no Servidor
Como Usar vmstat para Achar Gargalo no Linux em Minutos
Load Average no Linux: Como Interpretar Corretamente
Como Achar Gargalo com Iostat: Guia Definitivo e Prático
Iowait Alto: Causas Reais e Soluções
Swap Alto com RAM Livre: Por Que Isso Acontece e como Resolver
Tuning de sysctl para Produção: Guia Definitivo de Performance Linux
Como Ajustar limits.conf no Linux: Guia para Alta Performance
OOM Killer e MySQL: Como Evitar que o Linux Mate seu Banco de Dados
Memory Leak Linux: Como Detectar e Corrigir
No space left on device com espaço livre? Como resolver (Guia Completo)
Como identificar processo que consome CPU no Linux (Guia Completo)
Como Limitar CPU por Processo no Linux com cgroups (Guia Completo)
Upgrade de CPU ou Otimizar? Guia Completo
RAM Cheia no Linux: O Guia Definitivo para Resolver Travamentos em 2026
Buffers e Cache: Quando Deixam de Ajudar e Viram um Problema?
Out of Memory (OOM): Causas Reais, Diagnóstico e Como Resolver
Como evitar OOM Killer Linux em Produção: Guia Definitivo 2026
Gargalo no Linux: Como Identificar se o Problema é CPU ou RAM?
Disco Lento no Linux: Guia Completo para Identificar e Resolver
Latência de Disco no Linux Alta: Causas, Diagnóstico e Soluções