Carga da CPU no Mac: load average, processos e por que os testes travam

Em 31 de outubro de 2026, o hook de pre-commit do ArchFlow começou a estourar o tempo. Os testes de interface demoraram entre 100 e 800 segundos, e o uptime mostrava um load average de 144. Nenhum código novo tinha quebrado nada. A máquina estava com uma fila enorme de processos esperando a CPU, e os principais responsáveis eram a máquina virtual do Docker Desktop, com cerca de dez contêineres ligados, e um jogo. Fechar o Docker e um jogo derrubou a carga de 144 para cerca de 25.

No dia seguinte o problema voltou com outro culpado. Em 1 de novembro de 2026, um commit foi barrado porque o teste TextDialog > handles apply actions passou dos 5 segundos de limite. A carga estava entre 84 e 97, e o processo que mais consumia CPU era um git rodando em segundo plano dentro do GitHub Desktop, com cerca de 760% de CPU. Fechar o app levou a carga de 90 para 47, e o commit passou.

Esta aula explica o que esses números significam, como descobrir quem está consumindo a máquina e por que um teste que passa numa hora falha noutra sem que ninguém tenha mexido em nada. Os dois casos aparecem de novo no fim, depois que o mecanismo já foi explicado.

Mapa da aula

1. O que é load average

Imagine a fila de um caixa de supermercado com seis atendentes. Cada cliente é uma tarefa que quer ser atendida, e cada atendente é um núcleo da CPU. Se a fila está quase sempre vazia, os atendentes ficam parados. Se os clientes chegam mais depressa do que são atendidos, a fila cresce e ninguém sai do lugar. O load average é uma medida dessa fila: quantas tarefas estão prontas para rodar, em média, ao longo do tempo.

Tecnicamente, load average é a média, com decaimento exponencial, do número de tarefas prontas para rodar. Uma tarefa está pronta quando o programa quer a CPU agora e não consegue tê-la de imediato. O macOS mostra essa média como três números, referentes aos últimos 1, 5 e 15 minutos. Basta digitar uptime no terminal para vê-los:

$ uptime
11:23AM  up 3:01, 8 users, load averages: 21.09, 15.43, 12.79

A saída acima é o exemplo da própria página de manual do uptime no macOS. O primeiro número é a média do último minuto, o segundo a dos últimos cinco e o terceiro a dos últimos quinze. O mesmo valor pode ser lido com sysctl -n vm.loadavg, que devolve os três números entre chaves, na mesma ordem. Esse segundo comando é mais útil em scripts, porque sempre usa ponto como separador decimal, algo que a saída do uptime nem sempre faz.

Uma ressalva que a documentação do macOS não resolve sozinha: a página do uptime diz o que é mostrado, mas não detalha como a média é calculada no kernel. A leitura desta aula segue o conceito clássico do Unix, que conta tarefas prontas para rodar. No Linux, a conta também inclui processos parados esperando disco, o que faz o número subir por causa de leitura e escrita, e não só de CPU. Não conferi no código do kernel do macOS se a contagem é idêntica. Trate essa parte como lacuna.

2. Como ler o número

Um load average só significa algo quando é comparado com o número de núcleos. Com quatro núcleos e load 3, cada núcleo tem em média menos de uma tarefa esperando, e a máquina está folgada. Com quatro núcleos e load 12, a fila tem em média três tarefas por núcleo, e cada uma espera o seu turno. O número cresce a cada tarefa que chega e não consegue rodar, e cai quando a fila esvazia.

Para um Mac comum, a régua que circula por aí é esta: abaixo de 10 a máquina está tranquila, e acima de 20 há sobrecarga. Ela funciona como ponto de partida, mas tem uma nuance importante. O normal dessa máquina fica perto de 20 em dias comuns de trabalho, o que mostra que a régua depende do hardware e do que está rodando em segundo plano. Por isso o número sozinho diz pouco. O que costuma importar é o salto em relação ao seu próprio normal. Subir de 20 para 90 é um problema, mesmo que 90 não seja, em tese, absurdo para todas as máquinas.

Existe ainda um detalhe que confunde quem chega aqui: load alto não quer dizer que a CPU esteja 100% ocupada. Ele diz que há tarefas esperando. Uma tarefa pode estar esperando disco, rede ou um lock, e isso também conta em algumas implementações, como o Linux. Por isso o load average é um sintoma, e não um diagnóstico. Ele diz que algo está acontecendo, e você precisa olhar os processos para saber o quê.

3. A fila e os núcleos

O sistema operacional divide o tempo dos núcleos em fatias pequenas e distribui essas fatias entre as tarefas prontas. Cada programa aberto pode ter várias threads, e cada thread quer a sua fatia. Um Chrome com várias abas, um VS Code indexando o projeto e um container rodando um banco de dados, todos pedem CPU ao mesmo tempo. Quando há mais pedidos do que núcleos, parte deles fica na fila, e o tempo que eles passam esperando é exatamente o que o load average registra.

A figura abaixo mostra essa fila com os programas do Caso 1. Os pacotes que saem de cada caixa são threads prontas, e o que atravessa a fila até os núcleos é o que está sendo atendido. A cor rosa marca os programas que mais empurraram a fila naquele momento, e a laranja marca o teste, que foi quem sofreu com a espera.

Repare que o gargalo não é o número de programas abertos. Dezenas de apps quietos quase não pesam. O que pesa é quantas threads querem rodar ao mesmo tempo, e quanto tempo cada uma precisa de CPU antes de devolver a vez. Por isso dois programas com a mesma quantidade de janelas podem ter efeitos completamente diferentes no load.

4. As três janelas de tempo

Os três números do uptime não são três medições diferentes. São a mesma série de carga, suavizada em janelas de tamanhos diferentes. A média de 1 minuto reage rápido: sobe logo que a fila cresce e cai logo que ela esvazia. A de 15 minutos reage devagar: demora para subir e demora ainda mais para voltar ao normal. A de 5 fica no meio.

Essa diferença ensina a ler o padrão. Se o número de 1 minuto está alto e o de 15 está baixo, a carga começou agora. Se o de 15 está alto e o de 1 está baixo, a carga já passou e a máquina está se recuperando. Se todos estão altos, algo está rodando há um bom tempo. O gráfico abaixo usa uma carga instantânea inventada para ilustrar o efeito, não uma medição real. A linha tracejada é a carga de um instante, e as três curvas coloridas são as médias.

O gráfico mostra por que a média de 15 minutos engana quem olha só para ela. Depois do pico, a curva de 15 minutos continua alta por vários minutos, mesmo com a carga real já baixa. Quem confia nela para decidir se pode rodar um teste pesado agora espera mais do que precisava. Quem confia só na de 1 minuto pode começar no meio de um pico passageiro. Para decidir uma ação, a de 1 minuto costuma ser a mais honesta do momento, e as outras servem para entender o contexto.

5. Como achar o culpado

Quando o load sobe, a primeira pergunta é quem está ocupando a fila. Há três jeitos de responder, do mais rápido ao mais completo. O primeiro é uma foto da lista de processos, ordenada pelo consumo de CPU:

ps -A -o pcpu,comm -r | head -n 10

O -r ordena pela CPU, e o -A inclui os processos de todos os usuários. Os nomes aparecem com o caminho completo do executável, o que ajuda a reconhecer o app. Não se assuste com linhas do tipo Helper (Renderer): é o jeito de apps baseados em Chromium e Electron, como Chrome, Discord, VS Code e Obsidian, mostrarem os processos que fazem o trabalho pesado das abas e das janelas. O app pai pode estar quieto enquanto um desses filhos gira a 100%.

O segundo jeito é o top, que atualiza a lista em tempo real. Com top -o cpu você vê os processos ordenados pelo uso de CPU, e a atualização acontece a cada poucos segundos. Ele é melhor que o ps quando a carga está oscilando, porque mostra o valor do momento e não uma foto. A página de manual do próprio macOS traz um exemplo com top -o cpu -O +rsize -s 5 -n 20, que ordena por CPU, desempata por memória e atualiza a cada 5 segundos.

O terceiro jeito é o Activity Monitor, o monitor gráfico do macOS. Na aba CPU, a coluna % CPU mostra o mesmo que o top, e dá para filtrar por nome. Para quem está começando, ele é o caminho mais natural. Para investigar um caso específico, o terminal é mais preciso, porque você copia o nome exato do processo e pode repetir a mesma busca depois, num script.

Um cuidado antes de matar um processo: descubra de que app ele é filho. Fechar um helper isolado costuma só reiniciá-lo. Fechar o app inteiro costuma resolver, mas perde o estado não salvo. No Caso 2 o culpado era um comando do git, que o GitHub Desktop lança sozinho. Fechar o app foi a forma de parar o comando, e não o comando em si.

6. Por que uma VM é cara

O Docker é um caso à parte porque os contêineres são um recurso do Linux. Um contêiner usa o kernel do sistema em que roda, e o macOS não é Linux. Para rodar contêineres num Mac, o Docker Desktop precisa de uma máquina virtual Linux, e os contêineres rodam dentro dela. A documentação oficial do Docker descreve isso ao dizer que o Docker Desktop oferece vários gerenciadores de máquina virtual para alimentar a VM Linux que roda os contêineres. Um deles é o framework de virtualização da própria Apple. A documentação não diz qual gerenciador é o padrão no Mac, então esta aula não afirma isso. O que se observa nessa máquina é o processo chamado com.apple.Virtualization.VirtualMachine, que é o nome do processo que roda a VM.

Essa arquitetura explica por que a VM aparece como um vilão no monitor. Do ponto de vista do macOS, a VM é um único processo, e o ps mostra a soma de tudo que acontece lá dentro. Se dez contêineres estão brigando por CPU dentro da VM, o monitor do Mac só vê uma linha, com um número alto. Por isso, no Caso 1, a VM apareceu com mais de 300% de CPU, sem que nenhum contêiner individual aparecesse na lista do Mac.

A figura abaixo mostra as duas visões. À esquerda está o que o ps enxerga, uma linha só. À direita está o que acontece dentro da VM, onde o kernel Linux agenda os contêineres e cada um consome a sua parte da CPU que a VM recebeu.

A VM tem um custo extra além da soma. Cada contêiner que faz leitura de disco ou rede precisa atravessar a fronteira entre a VM e o macOS, e isso também consome CPU. Por isso, desligar contêineres que não estão em uso reduz a carga mesmo quando eles parecem parados. Um banco de dados ocioso quase não gasta CPU, mas um Prometheus coletando métricas, um Grafana com painéis abertos e uma suíte de testes rodando em loop, somados, pesam bastante. O Caso 1 mostrou exatamente isso: fechar o Docker tirou a maior parte da carga.

7. Apps que parecem ociosos

Um app com a janela minimizada parece não fazer nada, e a intuição é achar que ele não pesa. Essa intuição erra com frequência, porque muitos apps de interface passam o trabalho pesado para processos filhos. O GitHub Desktop é um bom exemplo. A janela pode estar parada, mas ele mantém os repositórios acompanhados e chama o git para checar o estado de cada um. Docker e os jogos seguem o mesmo padrão: a interface é pequena, e o trabalho real acontece numa VM ou em processos de atualização.

Para entender por que um git status pode pesar, pense no que ele faz. O comando compara o índice do git com os arquivos reais da pasta, e para isso precisa olhar os metadados de cada arquivo rastreado ou novo. Um repositório com dezenas de arquivos novos, conflitos ainda não resolvidos e uma pasta node_modules enorme tem muito mais itens para olhar do que um repositório limpo. O git também tenta atualizar o índice quando encontra mudanças, e isso exige um lock, que é uma trava para evitar que dois processos escrevam ao mesmo tempo. A opção --no-optional-locks existe para que o git status faça só o que é leitura e deixe essas escritas opcionais de lado. A página de manual do git (versão 2.54, instalada no Mac consultado) diz que essa opção impede operações opcionais que exigem locks, e equivale a definir GIT_OPTIONAL_LOCKS=0.

A figura abaixo mostra a cadeia que eu acredito ter acontecido no Caso 2. Ela é uma inferência: o consumo de 760% foi medido no processo, mas a ligação entre cada mudança de arquivo e o git status disparado pelo GitHub Desktop não foi medida diretamente. A linha tracejada marca essa parte.

Vale notar o que a figura não mostra: outras causas possíveis. A indexação de arquivos do macOS, por exemplo, também varre pastas grandes quando há muitas mudanças, e não foi descartada. A conclusão útil fica de pé mesmo assim. Um app que parece quieto pode estar fazendo muito trabalho em nome de um repositório que você esqueceu de olhar, e a única forma de confirmar é olhar a lista de processos enquanto a carga está alta.

8. Por que teste com timeout falha por carga

Um teste com timeout tem um limite de tempo: se não terminar nesse prazo, é considerado falho. A documentação do Vitest define 5000 milissegundos como o valor padrão de testTimeout em Node.js, e é esse o limite que o teste do Caso 2 atingiu. O ponto essencial é que o timeout mede tempo de parede, o relógio que anda sozinho, e não tempo de CPU que o teste consumiu. O teste não sabe por que demorou. Ele só vê que o relógio passou do limite.

Quando a máquina está sobrecarregada, o teste recebe menos fatias de CPU, e cada passo dele leva mais tempo para acontecer. Uma tarefa que precisa de meio segundo de CPU pode levar vários segundos numa fila de 90. Se o limite é de 5 segundos e a espera some a maior parte do tempo, o teste falha exatamente como falharia se houvesse um bug. A diferença está na causa, e não no sintoma.

Por isso a falha pode parecer aleatória. O mesmo teste passa numa máquina ociosa e falha numa carregada, sem que nenhuma linha de código tenha mudado. O Caso 2 mostra essa confusão de perto: o teste TextDialog > handles apply actions estourou o limite de 5 segundos com a carga entre 84 e 97, e o commit foi barrado por causa dele. A figura abaixo compara os dois desfechos com o mesmo hook e o mesmo teste.

Há um jeito prático de separar bug de carga. Quando um teste falha por timeout, espere a carga cair e rode o mesmo teste de novo, isolado. Se passar, o problema estava na máquina, e não no código. Se falhar de novo com a máquina tranquila, então sim há um bug ou uma lentidão real. Essa verificação leva um minuto e evita uma das perdas de tempo mais comuns: caçar um bug que só existe sob carga.

Uma lição extra vem do Caso 2. Outra ferramenta de IA também estava rodando testes na mesma máquina. Cada agente que roda testes soma carga na mesma fila, e o hook de pre-commit não sabe disso. Com um timeout de 5 segundos, qualquer pico vira falha. Esse limite é frágil quando a máquina é compartilhada, e vale considerar aumentá-lo para o hook, ou reduzir o número de testes que ele dispara.

9. Como esperar a carga baixar

Se você precisa rodar uma tarefa pesada, como uma suíte de testes de interface, o mais barato é esperar a carga cair antes de começar. Isso não exige nenhuma ferramenta especial. Basta um laço que lê o load average, compara com um limite e dorme antes de tentar de novo. O script abaixo usa o load de 1 minuto, que reage rápido, e roda a tarefa quando o valor fica abaixo de 20.

#!/bin/bash
LIMITE=20
while true; do
  carga=$(sysctl -n vm.loadavg | tr -d '{}' | awk '{print $1}')
  if awk -v c="$carga" -v l="$LIMITE" 'BEGIN { exit !(c < l) }'; then
    break
  fi
  sleep 30
done

O script usa sysctl em vez de uptime por um motivo prático: o separador decimal do sysctl é sempre o ponto, o que evita erros quando o terminal está configurado com números em português. Não testei o uptime com essa configuração, então o motivo é de cautela, não de medição. O intervalo de 30 segundos e o limite de 20 são escolhas, não números medidos, e você deve ajustá-los à sua máquina. A figura abaixo desenha a mesma lógica.

Há um cuidado com o laço. Ele espera para sempre se a carga não cair, então convém colocar um tempo máximo de espera, ou pelo menos um aviso no terminal. Também vale perceber que esperar não resolve a causa. Se o culpado é um processo que volta sozinho toda vez que você abre o app, a carga volta junto, e o laço só empurra o problema para depois.

10. Caso 1: Docker e um jogo em 31 de outubro de 2026

No dia 31 de outubro de 2026, o hook de pre-commit do ArchFlow rodava vitest related, que executa apenas os testes ligados aos arquivos alterados. Mesmo assim, os testes de interface estouraram o tempo, na faixa de 100 a 800 segundos, com load average de 144. Um valor desse tamanho significa uma fila de dezenas de tarefas por núcleo. Nenhum teste tinha mudado de comportamento.

Ao rodar ps aux -r, os processos no topo eram a VM do Docker Desktop, com mais de 300% de CPU, e uma lista de apps: um aplicativo de cliente Git com o git em segundo plano, o navegador, um comunicador, o editor de código e um assistente de IA. A VM tinha cerca de dez contêineres ligados, entre eles bancos de dados, ferramentas de monitoramento e aplicações de teste. Fechar o Docker e um jogo derrubou a carga de 144 para cerca de 25.

O que este caso ensina é a combinação de causas. Nenhum app sozinho explicava a carga de 144. A VM concentrava a maior parte, e a lista de apps abertos somava o resto. Quando a carga é alta, a pergunta certa não é “qual é o vilão”, e sim “quanto cada um tira da fila”. Fechar os dois maiores resolveu a maior parte do problema, e o restante seguiu tranquilo.

11. Caso 2: o git do GitHub Desktop em 1 de novembro de 2026

No dia seguinte, um commit foi barrado pelo hook de pre-commit. O vitest related rodou 115 arquivos, e o teste TextDialog > handles apply actions estourou o timeout de 5 segundos. A carga estava entre 84 e 97. O normal dessa máquina fica perto de 20, então o número estava quase cinco vezes acima do habitual.

Com ps aux -r, o processo que mais consumia CPU era o git --no-optional-locks embutido no GitHub Desktop, com cerca de 760% de CPU. O repositório do ArchFlow estava numa situação típica de trabalho em andamento: dezenas de arquivos novos, incluindo exemplos gerados, branches empilhados, trabalho não commitado e conflitos de merge marcados como UU, além de muitos arquivos dentro de node_modules. Fechar o GitHub Desktop derrubou a carga de 90 para 47, e o commit passou na tentativa seguinte.

A causa exata não foi medida. O que se mediu foi o processo e a queda de carga ao fechar o app. A explicação de que o git status em segundo plano é o motivo, e de que ele roda a cada mudança, é uma inferência coerente com os sintomas, mas não está provada. O teste falhou por carga, e não por bug: esse é o fato que importa para o código. O ajuste que ficou para depois é de configuração, no tamanho do timeout e no número de arquivos que o repositório deixa sem organizar.

12. Erros comuns e boas práticas

O erro mais frequente é tomar um timeout por bug. Quando um teste falha de repente, a reação natural é abrir o código e procurar a mudança que quebrou. Antes disso, vale rodar o uptime. Se o load está muito acima do normal, a primeira hipótese é carga, e não código. Quem nunca gastou uma tarde caçando um bug que só existia com o Docker ligado ainda não procurou o suficiente.

O segundo erro é fechar apps no escuro. Fechar tudo de uma vez pode até resolver, mas você não aprende nada e não sabe qual app voltar a abrir com cuidado. Use ps -A -o pcpu,comm -r | head -n 10 antes, anote os dois ou três maiores consumidores e feche só eles. Assim você descobre quais dependências pesam e pode tomar decisões depois.

O terceiro erro é ler o load sem o número de núcleos e sem o normal da própria máquina. Um 20 pode ser tranquilo numa máquina e um alerta em outra. Guarde um valor de referência para a sua máquina, observado num dia comum, e compare com ele.

O quarto erro é colocar um timeout apertado em um hook que roda o tempo todo. Um hook de pre-commit deve ser rápido e confiável, e um limite de 5 segundos falha por qualquer pico. Quando o hook depende de testes de interface, o timeout precisa acomodar a carga real da máquina, ou o hook precisa rodar menos testes. O custo de uma falsa falha é o desenvolvedor perdendo a confiança no hook e aprendendo a ignorá-lo, e isso é pior do que a lentidão.

O quinto erro é ignorar apps que parecem quietos. O cliente Git, o Docker e os jogos não exigem atenção na tela, mas podem ser os maiores consumidores da máquina. Olhe para os processos, e não para as janelas.

Como boa prática, guarde o hábito de checar a carga antes de rodar uma tarefa pesada, use o laço da seção 9 quando a tarefa puder esperar, e mantenha as VMs e os contêineres só com o que está em uso. Para o git, mantenha o repositório organizado: arquivos gerados fora do controle de versão, branches que já foram mesclados apagados e conflitos resolvidos reduzem o trabalho de cada git status.

13. Prática

1. Rode uptime três vezes, com um minuto de intervalo, e anote os três números de cada vez. Explique, em uma frase, o que o aumento ou a queda do primeiro número indica em relação ao terceiro.
2. Com o terminal aberto, rode ps -A -o pcpu,comm -r | head -n 10 e identifique cada linha. Para cada processo do topo, diga de qual app ele é filho e se você esperava que ele estivesse consumindo CPU naquele momento.
3. Abra o Docker Desktop com um contêiner ocioso e outro que faz um loop de trabalho, por exemplo um sleep seguido de cálculo em shell. Observe a linha da VM no top -o cpu e compare o número com o que você espera de cada contêiner. Descreva por que o monitor mostra uma linha só.
4. Escreva um teste propositalmente lento, que faz um cálculo longo e tem um timeout de 1 segundo. Rode-o com a máquina tranquila e depois com um processo de carga pesada rodando em paralelo. Anote o que mudou e explique por que o teste falha sem ter bug.
5. Adapte o script da seção 9 para aceitar o limite e o intervalo como argumentos. Teste com um limite muito alto e com um limite muito baixo, e confirme que o laço termina no primeiro caso e continua no segundo.

Glossário

Load average: média, com decaimento exponencial, do número de tarefas prontas para rodar, mostrada em janelas de 1, 5 e 15 minutos.

Núcleo: unidade de processamento da CPU capaz de executar uma tarefa por vez. Em uma CPU com vários núcleos, várias tarefas podem rodar em paralelo.

Thread: sequência de execução dentro de um programa. Um app pode ter muitas threads, e cada uma disputa a CPU separadamente.

Timeout: limite de tempo depois do qual um teste ou uma operação é considerado falho, independentemente da causa da lentidão.

Máquina virtual: programa que simula um computador inteiro dentro de outro. No Mac, o Docker usa uma VM Linux para rodar contêineres.

Contêiner: ambiente isolado que roda uma aplicação com suas dependências, compartilhando o kernel do sistema hospedeiro. No Mac, esse kernel fica dentro da VM.

Processo filho (helper): processo que um app lança para fazer um trabalho específico, como renderizar uma aba ou executar um comando do git. Pode consumir CPU mesmo quando a janela principal parece parada.

Lock: trava usada para impedir que dois processos escrevam ao mesmo tempo no mesmo recurso. No git, ela protege o índice.

Activity Monitor: monitor gráfico de processos do macOS, com a aba CPU para ver o consumo de cada programa.

Fontes

Consultadas em 1 de novembro de 2026.

• Página de manual do uptime no macOS (macOS 27), no próprio Mac, com o exemplo de saída e a descrição das três médias.
• Páginas de manual do ps e do top no macOS, no próprio Mac, para as opções -r, -A, -o cpu e -s.
• Página de manual do git 2.54 (Apple Git-157), no próprio Mac, para a opção --no-optional-locks e a equivalência com GIT_OPTIONAL_LOCKS=0.
• Virtual Machine Manager for Docker Desktop on Mac: os contêineres rodam numa VM Linux, e há vários gerenciadores de VM possíveis. A página não informa qual é o padrão no Mac, e esta aula também não afirma isso.
• Vitest: testTimeout: valor padrão de 5000 ms para Node.js, obtido por busca na documentação oficial. Não li a página inteira.
• Linux load averages, de Brendan Gregg: a explicação de que o Linux inclui processos em espera de I/O no load average. Consultei por busca e não li o artigo inteiro. Não foi possível confirmar, nas fontes consultadas, a contagem exata usada pelo macOS.
• Os dados dos casos de 31 de outubro e 1 de novembro de 2026 vêm de medições feitas numa única máquina, e não de uma fonte externa. A causa exata do Caso 2 não foi medida, e a aula diz isso no texto.

Relacionados

• Profiling
• Docker
• Git
• concorrência