Container travando? Como auditar limites de CPU e memória

Por que seu container parece lento ou trava do nada?

Quando uma aplicação roda dentro de um container Docker, ela compartilha o mesmo núcleo do sistema operacional do computador principal, chamado de host. Muitas vezes, percebemos que a aplicação engasga, demora para responder ou parece travada, mas as ferramentas comuns de monitoramento mostram que ainda sobra espaço. Na prática, isso significa que a aplicação pode estar sofrendo de um estrangulamento invisível de recursos, onde o sistema restringe o ritmo de trabalho sem avisar a aplicação diretamente. Para entender a fundo como evitar esses problemas, vale a pena conferir nosso guia sobre como limitar recursos com cgroups v2 para garantir estabilidade operacional.

Esse comportamento misterioso costuma acontecer porque o Docker utiliza uma tecnologia interna do Linux chamada cgroup, abreviação para grupos de controle. O cgroup funciona como um porteiro rigoroso que fiscaliza o consumo exato de processador, memória e disco de cada programa em execução. Se o container tenta usar mais do que o combinado no contrato de configuração, o porteiro entra em ação. Dependendo de como o ambiente foi configurado, ele pode simplesmente desacelerar o programa ou encerrar o processo abruptamente para proteger o servidor inteiro contra quedas catastróficas.

O que é o throttling de CPU e como ele estrangula suas aplicações?

O processador do computador divide o tempo em frações de milissegundos para atender a centenas de tarefas simultâneas. Quando definimos um limite de processamento para um container, o sistema operacional garante que ele não ultrapasse essa cota dentro de um período específico. Se o container gasta toda a sua fatia de tempo antes do período acabar, o sistema o coloca em pausa forçada até o próximo ciclo. Esse mecanismo é conhecido como throttling de CPU, ou seja, o estrangulamento da capacidade de processamento por falta de cota disponível.

Na rotina de engenharia, é muito comum confundir esse estrangulamento com falta de capacidade bruta do hardware. O servidor físico pode estar com os núcleos ociosos, mas o container específico continua travado porque bateu no teto de sua própria regra. Isso acontece frequentemente com aplicações pesadas escritas em linguagens que usam coletor de lixo, como Java ou Node.js, que realizam picos repentinos de processamento e acabam penalizadas pelas regras restritivas impostas pelo ambiente isolado.

Como auditar o uso real de CPU direto no sistema de arquivos do host

Para descobrir se o seu container está sofrendo com pausas forçadas, não precisamos instalar softwares complexos de monitoramento. O próprio kernel do Linux armazena todas essas estatísticas em arquivos virtuais organizados dentro da pasta onde o cgroup opera. No sistema moderno cgroup v2, por exemplo, o arquivo responsável por registrar as estatísticas de processamento chama-se cpu.stat. Podemos inspecionar esse arquivo diretamente no terminal do host para extrair números precisos sobre o comportamento do container.

Para realizar essa auditoria na prática, você pode seguir os passos abaixo usando o terminal do seu servidor Linux com privilégios administrativos.

1. Identifique o identificador único completo do container em execução rodando o comando tradicional de listagem.

   docker ps --no-trunc

2. Acesse o diretório correspondente ao container dentro da árvore de controle de recursos do sistema operacional.

   cd /sys/fs/cgroup/docker/<SEU_CONTAINER_ID>

3. Leia o arquivo de estatísticas de processamento para verificar a quantidade de interrupções sofridas.

   cat cpu.stat

Ao examinar o conteúdo retornado por esse arquivo, preste atenção especial em duas linhas fundamentale que aparecem na listagem: nr_throttled e throttled_usec. A primeira mostra quantas vezes o container foi freado por exceder a cota, enquanto a segunda revela o tempo total em microssegundos que a aplicação ficou congelada esperando o próximo ciclo. Se esses números sobem rapidamente enquanto a aplicação roda, você tem a prova matemática de que o limite configurado está estrangulando o serviço.

Entendendo os estouros de memória e o impacto oculto no sistema

Enquanto o processamento sofre pausas temporárias, o gerenciamento de memória nos containers lida com regras muito mais rígidas e diretas. Se um programa consome mais memória RAM do que o permitido, ele não ganha uma pausa para respirar; na maioria dos casos, o sistema operacional aplica uma punição severa e encerra o processo instantaneamente. Esse evento é conhecido como estouro de limite, gerando falhas inesperadas que muitas vezes são confundidas com erros de código na aplicação. Para complementar sua análise de estabilidade e entender os reflexos dessas ocorrências, consulte também nosso artigo sobre como auditar o OOM Killer com dmesg e descubra os registros deixados pelo sistema.

Para auditar o consumo real de memória sem depender de painéis externos, o cgroup v2 oferece o arquivo memory.current, que exibe exatamente quantos bytes o container está utilizando naquele milissegundo. Comparar esse valor com o limite máximo estipulado no arquivo memory.max permite prever falhas antes que o pior aconteça. Se o valor atual estiver constantemente colado no teto, a aplicação está prestes a sofrer uma interrupção forçada, exigindo um redimensionamento urgente da infraestrutura ou uma otimização no código fonte. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como inspecionar tráfego mTLS em pods no Kubernetes com cURL.

Considerações finais para manter containers estáveis e previsíveis

Auditar o comportamento de containers diretamente no host Linux através dos cgroups transforma a maneira como diagnosticamos problemas de performance em ambientes modernos. Em vez de adivinhar a causa raiz baseando-se em achismos, a leitura direta das métricas do kernel entrega dados concretos sobre throttling de CPU e pressão de memória. Dessa forma, conseguimos ajustar os limites dos containers com precisão cirúrgica, garantindo que os serviços rodem com alta performance, sem desperdício de hardware e livres de travamentos misteriosos no dia a dia.