Como Achar Gargalo com Iostat: Guia Definitivo e Prático

1. Introdução: O Inimigo Invisível da Performance

Na administração de sistemas e na engenharia de confiabilidade (SRE), o diagnóstico de performance é frequentemente comparado a um trabalho de detetive. Quando um servidor web começa a falhar ao entregar páginas, ou quando um banco de dados relacional (como MySQL ou PostgreSQL) começa a acumular conexões lentas, a reação instintiva da maioria dos profissionais é abrir o htop ou o top para verificar o uso de CPU e de memória RAM. Embora a CPU e a memória sejam componentes vitais, eles raramente são o verdadeiro gargalo em arquiteturas modernas. O verdadeiro culpado, na esmagadora maioria das vezes, reside no subsistema mais lento de qualquer computador: o armazenamento. É por isso que dominar a arte de achar gargalo com iostat não é apenas um diferencial, mas um requisito obrigatório para qualquer Sysadmin ou DevOps.

A diferença de velocidade entre a CPU e o disco é abismal. Enquanto um processador moderno executa ciclos na casa dos nanossegundos, um disco rígido mecânico (HDD) responde em milissegundos. Essa diferença de seis ordens de grandeza significa que, se a CPU tiver que esperar o disco buscar um dado físico nos pratos magnéticos, o sistema inteiro ficará em estado de espera (o famoso iowait). Até mesmo os modernos SSDs NVMe, embora infinitamente mais rápidos que os HDDs, possuem limites físicos de enfileiramento e paralelismo. Quando esses limites são atingidos, a latência dispara. Aprender a achar gargalo com iostat é o processo de iluminar essa caixa preta, permitindo que você veja exatamente como o sistema operacional está interagindo com o hardware de armazenamento.

Neste artigo extremamente aprofundado, vamos explorar muito além da superfície. Não vamos apenas mostrar o comando básico. Vamos mergulhar na arquitetura de I/O (Input/Output) do kernel Linux, dissecar cada flag do comando, entender o significado matemático por trás das métricas estendidas e, na segunda parte deste guia, aplicar esse conhecimento em cenários reais de desastre e otimização. Prepare seu terminal, pois vamos achar gargalo com iostat com precisão cirúrgica.

O iostat é uma ferramenta essencial para análise de disco e I/O. Para entender como aplicar esse diagnóstico na prática, veja o guia completo de performance de servidores Linux.

2. A Arquitetura de I/O do Kernel Linux

Antes de sequer digitar o comando no terminal, é crucial entender o que o iostat está realmente medindo. O utilitário não fala diretamente com o disco rígido; ele lê dados que o próprio kernel do Linux contabiliza. Para achar gargalo com iostat corretamente, você precisa entender o caminho que um dado faz desde a aplicação até o armazenamento físico.

Quando uma aplicação (como um servidor web) solicita a leitura de um arquivo, o pedido passa pelas seguintes camadas:

1. VFS (Virtual File System): A aplicação faz uma chamada de sistema (syscall) de leitura. O VFS é a camada de abstração que permite ao Linux lidar com diferentes sistemas de arquivos (EXT4, XFS, BTRFS) da mesma maneira.
2. Page Cache (Cache de Página): O kernel verifica se o dado já está na memória RAM. O Linux é agressivo em usar a memória livre como cache de disco. Se o dado estiver lá, temos um “cache hit”, a leitura é quase instantânea e o disco físico nem fica sabendo. O iostat não registrará isso como uma leitura de disco.
3. File System (Sistema de Arquivos): Se o dado não estiver no cache (cache miss), o pedido desce para o driver do sistema de arquivos específico, que traduz o nome do arquivo em blocos físicos de disco.
4. Block Layer (Camada de Bloco) e I/O Scheduler: É aqui que a mágica (e os problemas) acontecem. Os pedidos são colocados em uma fila. O I/O Scheduler (escalonador) decide a ordem em que esses pedidos serão enviados ao hardware para maximizar a eficiência (por exemplo, agrupando leituras de setores próximos no disco). Quando você tenta achar gargalo com iostat, grande parte das métricas de “fila” (aqu-sz) refere-se a esta exata camada.
5. Device Driver e Hardware: Finalmente, o pedido é enviado pelo driver da controladora (SATA, SAS, NVMe) para o hardware físico, que realiza o trabalho mecânico ou elétrico de buscar a informação e devolvê-la.

O iostat captura as estatísticas predominantemente na Camada de Bloco. Portanto, quando vemos um gargalo, estamos vendo o sofrimento do sistema operacional tentando empurrar dados através de um funil de hardware que não suporta a vazão ou a quantidade de requisições simultâneas.

3. Dissecando o Comando Iostat e as Flags Avançadas

O pacote de software que contém o iostat chama-se sysstat. Em distribuições baseadas em Debian/Ubuntu, você o instala com apt install sysstat.
Em RHEL/CentOS/AlmaLinux, usa-se yum install sysstat ou dnf install sysstat.

Se você rodar o comando iostat sem nenhum argumento, ele imprimirá um resumo rápido.
Atenção: Esse resumo inicial mostra a média de uso desde o momento em que o servidor foi ligado (o último boot). Usar essa tela inicial para diagnosticar um problema atual é um dos maiores erros de profissionais iniciantes. Para achar gargalo com iostat em tempo real, precisamos de um comando robusto e persistente.

O comando de ouro, o canivete suíço para SREs e Sysadmins, é:

Vamos quebrar o significado de cada uma dessas flags, pois a compreensão profunda delas é o que permite achar gargalo com iostat com eficiência:

• -d (Device): Esta flag diz ao utilitário para omitir as estatísticas de CPU. Quando seu foco é inteiramente o subsistema de armazenamento, os dados de processamento apenas ocupam espaço precioso na tela do terminal. Foco é essencial.
• -x (Extended): Esta é, sem dúvida, a flag mais importante de todo o utilitário. Sem ela, você obtém apenas taxas de transferência cruas (MB/s). Com o -x, o Linux expõe as estatísticas estendidas, revelando as métricas de latência (await), tamanho de fila (aqu-sz) e utilização (%util). É impossível achar gargalo com iostat de forma séria sem invocar a flag -x.
• -m (Megabytes): Historicamente, administradores de sistemas liam taxas de transferência em blocos ou kilobytes. Hoje, com discos de alta capacidade e redes velozes, ler 2500000 kB/s é confuso. A flag -m converte a saída de throughput para Megabytes por segundo (MB/s), tornando a leitura humana imediata. (Nota: você também pode usar -k para kilobytes se preferir maior granularidade em sistemas com pouquíssimo tráfego).
• -z (Zero): Em servidores empresariais modernos, é comum ter dezenas, centenas ou até milhares de LUNs (Logical Unit Numbers) anexados via Fiber Channel ou iSCSI. Se você não usar a flag -z, o terminal será inundado por uma lista infinita de discos inativos. O -z diz ao comando: “Mostre-me apenas os discos que tiveram atividade no último intervalo”. Isso limpa a interface e destaca os culpados imediatamente.
• 1 (Intervalo): O número no final indica o intervalo em segundos entre cada atualização da tela. Usar 1 segundo fornece uma visão altamente granular e imediata, perfeita para observar picos súbitos (spikes) de I/O. Se a tela estiver rolando rápido demais e dificultando a leitura, você pode alterar para 2 ou 5 segundos para obter médias um pouco mais consolidadas.

Você também pode adicionar um segundo número ao final, por exemplo iostat -dxmz 1 10, o que fará o comando rodar a cada 1 segundo, repetindo o processo 10 vezes e depois finalizando sozinho. Isso é extremamente útil para enviar relatórios ou automatizar a coleta em scripts de bash.

Interpretar os dados do iostat é apenas o começo. Para melhorar o desempenho do sistema, confira como otimizar a performance de servidores Linux.

4. Mergulho Profundo nas Métricas Estendidas

Quando a saída rolar na sua tela com as flags estendidas ativadas, você verá mais de dez colunas diferentes. Para achar gargalo com iostat com maestria, você precisa saber ignorar o ruído e focar nos indicadores críticos de saturação. Vamos analisar as colunas mais importantes, da esquerda para a direita, como elas aparecem em sistemas Linux modernos.

4.1. Taxa de Transferência vs. IOPS (r/s, w/s, rMB/s, wMB/s)

A primeira coisa que precisamos diferenciar é Throughput (Vazão/Taxa de Transferência) de IOPS (Operações de Entrada e Saída por Segundo).

• r/s (Reads per second): O número de solicitações de leitura emitidas para o dispositivo por segundo.
• w/s (Writes per second): O número de solicitações de gravação emitidas para o dispositivo por segundo.

Juntos, r/s e w/s formam o seu IOPS total. Se você quer achar gargalo com iostat, você precisa saber o limite do seu hardware. Um disco rígido mecânico de 7200 RPM, por uma limitação da física do braço de leitura que precisa se mover pelos pratos magnéticos, aguenta cerca de 80 a 150 IOPS no máximo. Um SSD SATA comum pode chegar a 80.000 IOPS, e um NVMe empresarial passa fácil de 500.000 IOPS. Se o seu r/s somado ao w/s estiver batendo no limite teórico do fabricante do disco, você encontrou o teto físico da sua infraestrutura.

• rMB/s e wMB/s: Estes representam o throughput bruto de leitura e gravação em Megabytes por segundo. É vital cruzar essa informação com os IOPS. Por exemplo, você pode ter um número muito baixo de IOPS (ex: w/s = 5), mas um throughput altíssimo (wMB/s = 200). Isso indica I/O sequencial (como a cópia de um arquivo de vídeo gigante). Por outro lado, um IOPS muito alto (ex: r/s = 5000) com um throughput baixo (rMB/s = 10) indica I/O randômico em arquivos minúsculos (típico de bancos de dados como PostgreSQL ou MongoDB operando sob estresse).

4.2. As Métricas de Fusão (rrqm/s, wrqm/s, %rrqm, %wrqm)

A sigla “rqm” significa request merge (fusão de requisições). Lembra que falamos sobre o I/O Scheduler na arquitetura do kernel? Para ser mais eficiente, se o sistema operacional perceber que a aplicação quer ler o bloco de disco 100, e logo em seguida outra aplicação pede para ler o bloco 101, o escalonador junta (faz o merge) dessas duas requisições em um único pedido gigante para o hardware.

• rrqm/s e wrqm/s: Mostra o número de fusões de leitura e gravação por segundo.
• %rrqm e %wrqm: Mostra a porcentagem das requisições que foram fundidas.

Para achar gargalo com iostat, essas colunas indicam a eficiência do escalonador de disco. Se você vir números muito altos de fusão (alta porcentagem de %wrqm), o kernel está trabalhando perfeitamente para consolidar o tráfego sequencial antes de enviá-lo para o disco físico, economizando IOPS preciosos da controladora.

4.3. O Indicador Crítico: Latência (await, r_await, w_await)

Se você esquecer tudo deste artigo, lembre-se apenas disto: o await é o rei do diagnóstico. É impossível achar gargalo com iostat sem analisar rigorosamente a latência.

• await: Representa o tempo médio, em milissegundos (ms), que uma requisição de I/O levou para ser totalmente atendida. Esta métrica inclui o tempo que o pedido ficou na fila de espera do sistema operacional + o tempo real de serviço que o hardware levou para executá-lo.
• r_await: O mesmo que acima, mas exclusivamente para as leituras.
• w_await: O mesmo que acima, mas exclusivamente para as gravações.

O await é a tradução em números do que o usuário final está sentindo. O que é um valor aceitável?

• Discos NVMe: O await deve ser sub-milissegundo (0.1ms a 1ms). Se passar de 2-3ms de forma constante, há um problema de configuração, superaquecimento (thermal throttling) ou exaustão do dispositivo.
• Discos SSD (SATA/SAS): Deve ficar entre 1ms e 5ms.
• Discos Mecânicos (HDD): É normal flutuar entre 10ms e 20ms. Valores acima de 30ms já causam degradação perceptível nos serviços. Valores acima de 100ms significam que o servidor está paralisado (“congelando”).

Separar r_await de w_await ajuda a achar gargalo com iostat ao apontar a direção correta. Se apenas as gravações estão lentas (w_await alto, r_await baixo), o problema pode ser a exaustão do cache de gravação da controladora RAID, falha de bateria BBU (Battery Backup Unit), ou um processo massivo de log inundando o disco.

Identificar gargalos de I/O é fundamental, mas a solução exige ajustes no sistema. Veja a estratégia de otimização de servidores Linux.

4.4. A Fila de Desespero (aqu-sz ou avgqu-sz)

A coluna aqu-sz (antigamente chamada de avgqu-sz em versões mais antigas do sysstat) representa o tamanho médio da fila de requisições enviadas ao dispositivo.

Imagine a fila de um banco. O disco físico é o caixa. As requisições de I/O são os clientes. O aqu-sz mede quantas pessoas estão na fila esperando para serem atendidas em um dado momento.

Para achar gargalo com iostat confirmando saturação pura, olhe para esta coluna cruzada com a latência. Se o aqu-sz for consistentemente alto (por exemplo, 50, 100, 200), significa que o sistema operacional está bombardeando a controladora de disco com pedidos muito mais rápido do que ela consegue processar e devolver. Uma fila alta com um await alto é o sinal definitivo e inquestionável de que o subsistema de disco se tornou o gargalo absoluto de performance daquela máquina. É o sinal vermelho na sua dashboard de monitoramento.

4.5. A Enganosa Utilização (%util)

Finalmente, chegamos à coluna mais mal compreendida pelos administradores de sistemas: a Utilização (%util).

Essa métrica informa a porcentagem do tempo em que o disco esteve ativo executando alguma operação de I/O. Se durante um intervalo de 1 segundo, o disco passou 500 milissegundos processando requisições e 500 milissegundos ocioso, o %util será de 50%.

Por que ela é enganosa hoje em dia? No passado, na era dos discos rígidos únicos, um %util de 100% significava gargalo total. O disco só conseguia fazer uma coisa de cada vez. Hoje, ao tentar achar gargalo com iostat em ambientes modernos (RAID, SSDs, LUNs de Storage), o %util perdeu um pouco de seu peso de alerta vermelho. Um SSD moderno, graças à tecnologia NCQ (Native Command Queuing) e ao barramento PCIe no caso dos NVMe, consegue processar 32, 64 ou até 65.000 requisições simultâneas em paralelo.

Isso significa que um SSD pode estar com %util em 100% (porque está constantemente lidando com pequenos arquivos e nunca fica totalmente ocioso), mas seu await está em perfeitos 0.5ms e a fila (aqu-sz) está baixa. O dispositivo está 100% em uso, mas não está 100% saturado.

Portanto, a regra de ouro para achar gargalo com iostat é: Nunca julgue o desempenho de um disco apenas pelo %util. Sempre valide um %util alto confirmando se o await e o aqu-sz também estão altos.

5. Estudos de Caso Práticos: Lendo a Matrix

Agora que compreendemos a teoria profunda por trás das métricas estendidas, é hora de aplicar esse conhecimento. Saber achar gargalo com iostat na prática significa olhar para uma tela cheia de números oscilantes e identificar imediatamente o padrão de falha. Abaixo, detalhamos três dos cenários mais comuns enfrentados por administradores de sistemas em ambientes de produção.

O iostat deve ser utilizado junto com outras ferramentas para uma análise completa. Veja também:

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

Cenário A: O Banco de Dados em Colapso (Saturação de IOPS)

Você é chamado para investigar um servidor PostgreSQL que está recusando conexões ou apresentando tempos de resposta inaceitáveis. Você abre o terminal e executa iostat -dxmz 1.

• O que você vê: * O %util está travado em 99% ou 100%.
  • O w/s (gravações por segundo) está em 3.500.
  • O wMB/s está relativamente baixo (ex: 15 MB/s).
  • O w_await (latência de gravação) está flutuando entre 80ms e 150ms.
  • O aqu-sz (fila) está em 45.
• O Diagnóstico: Este é o exemplo clássico de exaustão de IOPS randômicos. O banco de dados está fazendo milhares de pequenas gravações espalhadas pelo disco. Embora o volume de dados (15 MB/s) não seja grande, a quantidade de operações (3.500) sobrecarregou a controladora. A fila (aqu-sz = 45) mostra que as requisições estão se acumulando mais rápido do que o disco consegue processar, e a latência de 150ms é a confirmação de que o sistema está agonizando.
• A Solução: Ao achar gargalo com iostat com este padrão, a solução de hardware envolve migrar para um disco com maior capacidade de IOPS (como um SSD NVMe empresarial) ou aumentar a alocação de IOPS provisionados (se estiver usando nuvem como AWS EBS ou Azure Disk). No lado do software, pode ser necessário otimizar queries, ajustar o checkpoint_timeout ou aumentar os buffers de memória do banco de dados para que ele faça mais gravações em lote (batching) em vez de gravações unitárias.

Cenário B: O Backup Silencioso (Saturação de Throughput)

Um servidor de arquivos Samba/NFS ou um servidor web apresenta lentidão intermitente, geralmente nos mesmos horários, mas a CPU e a RAM estão folgadas.

• O que você vê:
  • O %util bate 100%.
  • O r/s e w/s estão moderados (ex: 150 a 300).
  • O rMB/s ou wMB/s está altíssimo, batendo o limite teórico do barramento (ex: 120 MB/s em um HDD SATA III ou 500 MB/s em um SSD SATA).
  • O await está moderadamente alto (ex: 30ms).
• O Diagnóstico: Diferente do banco de dados, aqui o problema não é a quantidade de pequenas operações, mas o volume bruto de dados contínuos. Um processo está lendo ou gravando arquivos gigantescos de forma sequencial (como um dump de banco de dados, um rsync ou uma rotina de backup de madrugada), sugando toda a largura de banda do disco e deixando as aplicações web “na fila” esperando sua vez.
• A Solução: Aqui, achar gargalo com iostat salvou você de comprar hardware desnecessário. A solução não é trocar o disco, mas gerenciar a prioridade. Você pode usar o utilitário ionice no Linux para forçar o script de backup a rodar com classe de prioridade de I/O “Idle” ou “Best Effort” baixa, garantindo que as aplicações críticas tenham prioridade de acesso ao disco.

Cenário C: O Disco Moribundo ou Rede Problemática

O servidor está “congelando” completamente por vários segundos. Load average do Linux vai às alturas, mas a CPU está em 0% de uso (apenas iowait alto).

• O que você vê:
  • O %util flutua descontroladamente ou fica baixo (ex: 15%).
  • Os IOPS (r/s, w/s) estão incrivelmente baixos (ex: 5 a 10 operações por segundo).
  • O await está monstruoso, na casa dos 1.000ms a 5.000ms (1 a 5 segundos de latência!).
• O Diagnóstico: O disco passa a maior parte do tempo ocioso, mas quando recebe uma única requisição, demora uma eternidade para responder. Se for um disco físico local, isso é um forte indício de blocos defeituosos (bad blocks); a controladora está tentando ler um setor corrompido repetidas vezes até dar timeout. Se for um disco de rede (NFS, iSCSI, SAN), isso indica um problema grave de rede, rotas ou saturação no switch do Storage.
• A Solução: Inspecionar os logs do kernel imediatamente usando dmesg | tail ou olhar o /var/log/syslog. Se você vir erros de hardware ou falhas no barramento SCSI, prepare-se para substituir a unidade de armazenamento.

6. Ferramentas Complementares: O Ecossistema de Monitoramento

Uma regra de ouro da administração de sistemas é que nenhuma ferramenta responde a todas as perguntas. O objetivo primário ao achar gargalo com iostat é confirmar se o subsistema de armazenamento é a raiz do problema. No entanto, o iostat mostra estatísticas de hardware (por exemplo, /dev/sda está saturado), mas não diz quem está causando isso.

Para ter uma visão 360 graus, você precisa combinar o iostat com as seguintes ferramentas:

O Iotop

Assim que você achar gargalo com iostat e confirmar que o disco está sobrecarregado, deixe o comando rodando em um terminal e abra outro. Digite sudo iotop (ou sudo iotop -o para ver apenas os processos ativos). O iotop é como o gerenciador de tarefas top, mas focado exclusivamente na leitura e gravação de disco por processo. Ele mostrará exatamente qual programa (ex: mysqld, nginx, rsync, journald) está gerando a carga pesada que você detectou no iostat.

O Vmstat (Swapping)

Às vezes, ao tentar achar gargalo com iostat, você verá uma tempestade absurda de leitura e gravação, mas não há nenhum backup ou banco de dados pesado rodando. Nesses casos, o disco não é a causa do problema, é a vítima. Se o seu servidor ficar sem memória RAM, o kernel do Linux começará a usar o disco rígido como “memória virtual” (um processo chamado Paging ou Swapping). Como o disco é infinitamente mais lento que a RAM, o sistema inteiro trava. Use o comando vmstat 1. Se as colunas si (Swap In) e so (Swap Out) estiverem consistentemente altas, o seu disco está sendo esmagado pela falta de RAM. A solução aqui não é otimizar o I/O, mas sim adicionar mais memória ao servidor ou corrigir o vazamento de memória (memory leak) da aplicação.

7. Otimizações de Kernel e Filesystem (Resolução Prática)

Você conseguiu achar gargalo com iostat, usou o iotop para encontrar a aplicação, mas não há muito o que otimizar no código e você não tem orçamento para trocar os SSDs hoje. O que fazer? O Linux oferece alguns “botões” no nível do kernel que podem extrair performance extra do seu hardware existente.

7.1. Ajuste de I/O Schedulers

O I/O Scheduler é o algoritmo do kernel que decide a ordem em que as requisições chegam ao disco físico. Em HDDs rotacionais clássicos, escalonadores como cfq (Completely Fair Queuing) ou bfq são ótimos, pois organizam as leituras para minimizar o movimento físico da agulha do disco. No entanto, em SSDs ou NVMes, que não têm partes móveis e suportam paralelismo massivo, esses escalonadores complexos apenas adicionam latência de processamento de CPU. Para dispositivos de estado sólido ultra-rápidos, você geralmente deve alterar o escalonador para none ou mq-deadline.

Você pode verificar o escalonador atual de um disco (por exemplo, sda) com o comando:

cat /sys/block/sda/queue/scheduler 

cat /sys/block/sda/queue/scheduler 

Para alterar temporariamente e ver se a latência no iostat melhora:

echo none | sudo tee /sys/block/sda/queue/scheduler

echo none | sudo tee /sys/block/sda/queue/scheduler

7.2. Ajustes no Fstab (Mount Options)

Sempre que o Linux lê um arquivo, por padrão, ele atualiza um metadado no sistema de arquivos chamado “Access Time” (atime). Isso significa que, incrivelmente, toda operação de leitura gera uma operação de gravação no disco. Em servidores web que servem milhões de pequenas imagens ou arquivos HTML estáticos, isso gera uma carga de I/O assustadora e desnecessária. Você pode editar o seu arquivo /etc/fstab e adicionar a opção de montagem noatime (ou relatime, que é o padrão moderno em muitos sistemas) na partição. Isso desativa essa atualização constante de metadados, podendo aliviar a carga de gravação do disco em até 15-20% em servidores de alto tráfego.

7.3. A Escolha do Filesystem

A arquitetura do seu sistema de arquivos importa muito. O EXT4 é excelente, estável e o padrão para quase tudo. No entanto, se você está rodando bancos de dados massivos, sistemas como o XFS possuem algoritmos de alocação de metadados paralelizados muito superiores, reduzindo o gargalo de I/O quando múltiplas threads tentam gravar dados pesados simultaneamente. O simples fato de aprender a achar gargalo com iostat pode revelar que o seu EXT4 está sofrendo com travamentos de journaling, exigindo uma formatação estratégica em XFS.

Para transformar diagnóstico em melhoria real, consulte o guia de como otimizar servidores Linux.

O iostat deve ser utilizado junto com outras ferramentas para uma análise completa. Veja também:

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

FAQ: Perguntas Frequentes sobre I/O e Iostat

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
Iowait Alto: Causas Reais e Soluções
Swap Alto com RAM Livre: Por Que Isso Acontece e como Resolver
Guia Completo de Monitoramento Linux com vmstat, iostat e sar
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