Por que uma aplicação que rodava bem começa a engasgar depois de dias no ar — e como o SO decide quem morre quando a memória acaba.
PID, estados, escalonamento, concorrência — tudo sobre quem usa a CPU e quando.
Todo processo precisa de memória e de disco. Quando qualquer um dos dois acaba ou fica lento, a aplicação sofre — e você precisa saber diagnosticar.
O eixo do curso continua: containers seguem presentes, agora com um ângulo novo — limites de memória.
Ninguém mexeu no código. O tráfego foi normal. E mesmo assim a memória só subiu.
O SO dá a cada processo um espaço de endereçamento — a ilusão de ter a memória inteira só pra si. Dois processos podem usar o "endereço 1000" ao mesmo tempo, e são lugares fisicamente diferentes.
É isso que impede um processo de ler ou corromper a memória de outro — o mesmo isolamento que vocês já viram no namespace de PID do Encontro 5, agora aplicado à memória.
A confusão mais comum de quem começa: olhar o total de memória "usada" e entrar em pânico. O Linux usa memória livre como cache de disco de propósito — isso é bom, não é vazamento.
| Campo | O que significa | Devo me preocupar? |
|---|---|---|
| total | Memória física instalada | Referência, só isso |
| used | Em uso por processos + kernel | Sozinho, não diz muito |
| buff/cache | Cache de disco — devolvido quando alguém precisar | Não. É desejável estar alto |
| available | Quanto realmente dá pra alocar agora | Sim — este é o número que importa |
Um vazamento acontece quando o programa pede memória ao SO e, por um erro de lógica, nunca libera — mesmo já não precisando mais dela. A cada requisição atendida, o consumo sobe um pouco e nunca desce.
Consumo que só cresce ao longo do tempo, sem estabilizar — e que só volta ao normal quando o processo é reiniciado.
Acompanhar a memória do processo ao longo de horas/dias (não num instante só) e comparar com o padrão de tráfego.
A "solução" preguiçosa que muita equipe adota — reiniciar o serviço toda madrugada — é justamente o sintoma de um vazamento não corrigido.
Antes de desistir, o SO tem uma carta na manga: mover para o disco (swap) as partes da memória que estão paradas há mais tempo, liberando RAM para quem precisa agora.
Funciona, mas o disco é ordens de grandeza mais lento que a RAM — é por isso que a máquina "engasga" quando começa a usar swap pesado.
Se nem com swap houver memória, o kernel escolhe um processo e o mata — sem aviso, sem chance de salvar estado.
Quando não há mais memória, o kernel precisa matar alguém para o sistema inteiro não travar. Ele pontua cada processo e mata o de maior pontuação.
"O container morreu do nada" quase sempre é OOM. Saber ler esse log é o que separa o chute do diagnóstico.
Vazamento acumulando até estourar o limite — o reinício programado é paliativo, não correção.
Limite de memória do container atingido, OOM dispara, orquestrador sobe outro no lugar.
Em ambos, o diagnóstico começa exatamente pelos comandos que vocês vão rodar hoje.
/proc — como sempreDo Encontro 2 até aqui, o /proc não mudou de papel: é a janela do kernel. Para memória, os arquivos que interessam são poucos e diretos.
| Caminho | O que mostra |
|---|---|
| /proc/meminfo | Visão global da memória — o que o free -h resume |
| /proc/<pid>/status | Memória daquele processo específico (campos VmRSS, VmSize) |
| /proc/swaps | Áreas de swap ativas e quanto de cada uma está em uso |
Comandos como free e top são, de novo, apenas leitores organizados desses arquivos.
Aqui o Docker deixa de ser só empacotamento e vira ferramenta de controle de recurso: você define quanta memória aquele container pode usar, e o kernel faz valer.
Um vazamento dentro do container pode derrubar a máquina inteira, afetando todos os outros serviços.
--memoryAo estourar o limite, o OOM mata só o processo daquele container — o resto da máquina continua de pé.
Vocês vão provocar exatamente esse cenário hoje: um container com limite baixo, consumindo memória de propósito até morrer.
free -h ao container morto por OOMUma sequência real: ler a memória do sistema, acompanhar o consumo de um processo, e ver um container estourar o próprio limite.
Cada uma dessas linhas vira um passo do roteiro de laboratório de hoje.
free -h, /proc/meminfo, /proc/<pid>/status e o top ordenado por memória.
Subir um container com --memory baixo e provocar o estouro de propósito.
O roteiro de laboratório detalha os passos, com dicas se algo travar.
O meminfo e sua vizinhança, direto do laboratório — a base prática de hoje. p. 94–98
Por que cada processo enxerga "sua" memória, e o que o SO faz quando ela acaba. p. 128–131
Como era o mundo antes do espaço de endereçamento — bom pra dimensionar o problema que ele resolve. p. 125–128
O quiz da semana verifica essa leitura e recolhe suas observações da prática — tudo no mesmo instrumento.