O mecanismo que explica por que uma máquina "engasga" sem estar com a CPU cheia — e como impor tetos de memória a um container de forma consciente.
Vazamento, swap, OOM Killer — e o container morto com código 137 por estourar o próprio limite.
Paginação é o truque que permite rodar mais coisa do que cabe na RAM — e também a explicação de por que, em excesso, tudo fica lento.
Nada parece sobrecarregado — e nada responde. Onde está o gargalo?
Em vez de tratar a memória de um processo como um bloco contínuo, o SO a divide em páginas de tamanho fixo (tipicamente 4 KB). A RAM é dividida em molduras do mesmo tamanho, e o SO mantém uma tabela dizendo qual página está em qual moldura.
A consequência prática é poderosa: nem toda página precisa estar na RAM ao mesmo tempo.
Quando o processo acessa uma página que não está carregada, o hardware interrompe a execução e o SO assume: busca a página no disco, coloca numa moldura livre, atualiza a tabela, e devolve o controle ao processo — que nem percebe que isso aconteceu.
Page fault não é erro — é operação normal. O problema é a frequência dos que precisam ir ao disco: cada um desses custa um acesso milhares de vezes mais lento que a RAM.
Se há processos demais para a RAM disponível, o SO passa a expulsar páginas que serão pedidas de volta em seguida. O resultado é um ciclo vicioso: page fault → carrega do disco → expulsa outra página → novo page fault.
Máquina lentíssima, CPU baixa (ela está esperando disco, não calculando), e um volume alto e constante de E/S de swap.
Carga de trabalho maior do que a RAM comporta. Corrige-se reduzindo processos simultâneos, aumentando RAM ou impondo limites por serviço.
Era essa a resposta do slide 2: CPU baixa não significa máquina ociosa — pode significar que ela está travada esperando disco.
Swap é a área de disco usada para guardar páginas expulsas da RAM. Ter swap é saudável: dá folga ao sistema em picos e permite que páginas realmente ociosas saiam do caminho.
| Situação | Interpretação |
|---|---|
| Swap alocado, pouca E/S | Normal — páginas ociosas guardadas, sem custo de desempenho |
| Swap crescendo devagar | Atenção — carga aumentando, vale investigar |
| E/S de swap alta e constante | Thrashing — a máquina está gastando tempo trocando páginas |
Ou seja: não olhe só "quanto swap está em uso" — olhe quanta troca está acontecendo.
Conclusão comum e enganosa — leva a equipe a procurar o problema na aplicação, no banco, na rede, e a perder horas.
Reconhecer thrashing em minutos, em vez de horas, é uma vantagem concreta em sustentação e cloud.
No Encontro 9 vocês viram o limite matar um container. Isso pode parecer ruim — mas é exatamente o objetivo: transformar uma falha global e imprevisível numa falha local e previsível.
Um serviço com vazamento consome toda a RAM da máquina, força thrashing, e degrada todos os outros serviços antes de alguém perceber.
O serviço problemático morre sozinho, é reiniciado pelo orquestrador, e os demais seguem intactos. O incidente fica contido e visível.
| Opção | O que faz |
|---|---|
| --memory | Teto de memória RAM do container. Ao ultrapassar, o processo é morto (OOM) |
| --memory-swap | Teto de memória + swap somados. Igualar ao --memory desabilita swap para aquele container |
| docker stats | Acompanha o consumo contra o limite definido, ao vivo (visto no Encontro 6) |
Por baixo dos panos, é o mesmo mecanismo de cgroups do kernel Linux que vocês viram de relance lá no Encontro 2 — agora com um uso concreto.
Os livros de SO dedicam várias páginas aos algoritmos de substituição de página — as regras que decidem qual página expulsar quando a RAM enche (LRU, FIFO, relógio, e outros).
Fundamental para engenharia de sistemas operacionais e pesquisa — implementar o kernel exige escolher e otimizar esses algoritmos.
Saber que a expulsão acontece e reconhecer thrashing muda seu diagnóstico. Saber qual algoritmo específico o kernel usa, não.
Fica registrado como leitura opcional para quem tiver interesse — mas não é cobrado nesta disciplina.
Uma sequência real: contar page faults de um processo, acompanhar a troca de páginas com vmstat, e comparar dois containers com limites diferentes.
Cada uma dessas linhas vira um passo do roteiro de laboratório de hoje.
Medir page faults de um comando, ler as colunas de swap do vmstat e interpretar o que elas dizem.
Descobrir empiricamente o limite mínimo viável para um container, em vez de chutar.
O roteiro de laboratório detalha os passos, com dicas se algo travar.
O mecanismo que explica por que a máquina "engasga" — a leitura principal de hoje. p. 134–136
As mesmas páginas do Encontro 9, agora com novos olhos: você já sabe o que é page fault. p. 94–98
Aprofundamento para quem quiser ir além do recorte obrigatório. p. 134–144 e 155–156
Decisão de calibragem desta disciplina — relevante para engenharia de SO, não para o perfil ADS. Não é cobrado.
O quiz da semana verifica essa leitura e recolhe suas observações da prática — tudo no mesmo instrumento.