Load average e top: o que os números realmente dizem

load average: 8.42, 7.91, 6.33. Em uma máquina de 8 núcleos, esse número é motivo para preocupação ou sinal de aproveitamento perfeito?

A resposta honesta é que não dá para saber só com ele. O load average é a métrica mais citada e mais mal interpretada do Linux, porque mede algo diferente do que quase todo mundo supõe.

O que o load average mede de fato

Ele não é percentual de CPU. É a média do número de processos em estado executável ou ininterrompível — ou seja, processos rodando, mais processos esperando a vez na CPU, mais processos travados esperando disco.

Essa última parte é a que muda tudo. No Linux, ao contrário de outros sistemas Unix, espera por entrada e saída entra na conta. Uma máquina com CPU praticamente ociosa e um disco saturado apresenta load alto.

uptime
cat /proc/loadavg

Os três números são médias de 1, 5 e 15 minutos. A relação entre eles conta a história:

• 1min muito acima do 15min — algo começou agora. Pico em andamento.
• 1min bem abaixo do 15min — o pico passou, a máquina está se recuperando.
• Os três próximos — carga estável, seja ela alta ou baixa.

Para interpretar o valor absoluto, divida pelo número de núcleos:

nproc

Load 8 com 8 núcleos dá 1,0 por núcleo — plena utilização sem fila. Load 8 com 2 núcleos dá 4,0 por núcleo, e aí há fila real. O mesmo número, dois diagnósticos opostos.

O passo seguinte: CPU ou disco?

Load alto sozinho não diz onde está o gargalo. A separação leva dez segundos:

vmstat 1 5

Duas colunas respondem:

• r — processos prontos para rodar, esperando CPU. Consistentemente acima do número de núcleos significa CPU insuficiente.
• b — processos bloqueados esperando entrada e saída. Diferente de zero de forma sustentada significa disco.

E na seção de CPU:

• wa (iowait) alto com us e sy baixos é o retrato de disco saturado. A CPU está parada esperando.
• us alto é trabalho da aplicação. Legítimo, se o trabalho existir.
• sy alto é o kernel. Costuma indicar excesso de chamadas de sistema, troca de contexto ou rede muito ativa.

Load 8 com wa em 60% não é problema de CPU — aumentar vCPU não vai ajudar em nada. O caminho é investigar o disco ou reduzir a quantidade de escrita.

Lendo o top sem tropeçar

O top é onipresente e tem três armadilhas que levam a conclusões erradas.

A primeira leitura é lixo. O percentual de CPU da primeira tela é calculado desde o boot da máquina. Ignore-a e olhe a partir da segunda atualização.

O percentual pode passar de 100. Ele é por núcleo. Um processo com 380% está usando quase quatro núcleos, o que é ótimo se ele deveria paralelizar.

As colunas de memória enganam. Vale saber o que cada uma significa:

Somar a coluna RES de todos os processos dá um número maior que a memória da máquina, porque bibliotecas compartilhadas são contadas várias vezes. Não é bug.

Alguns atalhos que economizam tempo dentro do top: 1 mostra cada núcleo separado, M ordena por memória, P por CPU, c exibe a linha de comando completa — útil para distinguir cinco processos python entre si.

Se o htop estiver disponível, ele resolve boa parte disso visualmente. Vale instalar.

A métrica que o load não dá

O load average tem duas limitações estruturais: mistura CPU com disco, e não diz quanto de tempo foi efetivamente perdido esperando.

O indicador de pressão resolve as duas:

cat /proc/pressure/cpu
cat /proc/pressure/io
cat /proc/pressure/memory

Ele informa a porcentagem de tempo em que houve espera por cada recurso, separados. some avg60 acima de 10% em io significa que os processos passaram mais de um décimo do último minuto parados esperando disco — informação bem mais acionável que "load 8".

É a mesma métrica útil para memória, detalhada no artigo sobre o OOM killer.

Steal time: quando a culpa não é sua

Há uma coluna do top que só faz sentido em máquina virtual e que resolve uma categoria inteira de dúvida: o st, de *steal time*.

Ele mede o percentual de tempo em que a sua máquina virtual queria CPU e não recebeu, porque o hospedeiro estava atendendo outra. Do lado de dentro, o sintoma é uma aplicação lenta com uso de CPU aparentemente normal — os números não fecham, e não fecham mesmo: parte do tempo simplesmente não foi entregue.

top -b -n2 | grep '%Cpu' | tail -1
vmstat 1 5     # última coluna

Como interpretar:

• Abaixo de 1% — normal. Toda virtualização tem alguma sobrecarga.
• Entre 1% e 5% — perceptível em carga sensível a latência.
• Acima de 10% de forma sustentada — a máquina não está recebendo o que deveria.

Steal alto e constante é conversa com o provedor, não ajuste de sistema. Nenhuma otimização dentro da VM recupera CPU que não foi entregue. Vale documentar o período e os números antes de abrir o chamado — é a evidência que torna a conversa objetiva.

Vale também não confundir com carga própria: steal sobe naturalmente durante picos seus, quando você pede mais CPU do que a cota permite de forma sustentada.

Troca de contexto e o custo que não aparece

Duas linhas do vmstat costumam passar despercebidas e explicam lentidão sem gargalo aparente:

vmstat 1 5    # colunas cs e in

cs é a quantidade de trocas de contexto por segundo, e in a de interrupções. Cada troca custa: o kernel salva o estado de um processo e carrega o de outro, e o cache do processador é invalidado no caminho.

Valores muito altos — dezenas ou centenas de milhares por segundo em máquina pequena — indicam concorrência excessiva. As causas usuais são threads ou workers em número muito maior que o de núcleos, e disputa por trava dentro da aplicação.

O sintoma característico é CPU alta com pouca vazão útil: a máquina está ocupada gerenciando a si mesma. A correção costuma ser reduzir o número de workers, e não aumentá-lo — o que é contraintuitivo o suficiente para que quase ninguém tente primeiro.

Quando o load alto não é problema

Vale reforçar, porque muito alarme falso nasce daqui. Load alto é esperado e saudável em várias situações:

• Processamento em lote. Um servidor que roda transcodificação, indexação ou relatório deve ter load alto — é para isso que ele existe. Máquina ociosa é desperdício.
• Compilação. make -j8 gera load 8 de propósito.
• Backup e cópia grande. Load sobe por iowait, e passa.

O que importa não é o número, é o efeito: a aplicação continua respondendo dentro do esperado? Se sim, o load é apenas informação sobre uso de recurso.

Por isso o alerta deve ser sobre o que o usuário sente — latência, taxa de erro, tamanho de fila — e não sobre load. Alerta de load produz muita notificação irrelevante e treina o time a ignorar.

Um diagnóstico em ordem

Quando alguém reportar que "o servidor está com load alto", esta sequência resolve na maior parte das vezes:

uptime; nproc                  # o número é alto de fato?
vmstat 1 5                     # CPU ou disco?
top -b -n2 -o %CPU | tail -25  # quem está consumindo
cat /proc/pressure/io          # houve espera real?

Se a resposta for CPU e o consumo for legítimo, o caminho é ajustar o tamanho da máquina, que é aplicado em janela curta de manutenção.

Se for disco, aumentar CPU não muda nada — e a investigação segue por escrita excessiva, log sem rotação ou consulta sem índice.

E se o load estiver alto sem nenhum processo consumindo de forma visível, olhe processos em estado D, que é a espera ininterrompível:

ps -eo state,pid,comm | awk '$1 ~ /^D/'

Processo preso em D não responde nem a kill -9, porque está dentro de uma chamada de kernel. Costuma indicar disco com problema, ou sistema de arquivos de rede que parou de responder — e nesse caso o culpado raramente está na máquina que você está olhando.