Container Docker consumindo muita CPU? Como limitar recursos

O perigo silencioso do consumo descontrolado de CPU

Em ambientes de produção que rodam múltiplas aplicações isoladas, é comum que um único serviço mal otimizado acabe consumindo todo o processamento disponível na máquina física. Quando isso acontece, sistemas vizinhos que dependem do mesmo servidor sofrem com lentidão extrema ou simplesmente travam por falta de resposta. Para evitar esse tipo de colapso, entender como achar gargalos de CPU e memória em containers Docker torna-se o primeiro passo essencial antes de aplicar qualquer restrição definitiva de desempenho.

Na prática, o isolamento padrão oferecido pelo Docker garante que os programas rodem em seus próprios universos virtuais, mas não impede por si só que um deles sugue 100% dos núcleos de processamento. Sem uma política clara de governança de hardware, a infraestrutura fica vulnerável a picos repentinos de carga gerados por rotinas de backup, varreduras pesadas ou loops acidentais no código da aplicação. É exatamente nesse cenário crítico que entram os mecanismos de controle de recursos do kernel do sistema operacional.

O que são cgroups e como eles controlam o hardware

Por trás de toda a mágica dos containers no ecossistema Linux existe uma ferramenta fundamental chamada cgroups, abreviação para control groups ou grupos de controle. Na prática, trata-se de um recurso nativo do sistema operacional que serve para limitar, contabilizar e isolar o uso de recursos físicos — como processador, memória e disco — por parte de um grupo de processos. Pense nos cgroups como barreiras invisíveis que dizem exatamente quanta energia cada aplicativo pode consumir da máquina.

Quando você inicia um container, o Docker instrui o kernel do Linux a alocar esse grupo isolado de regras para aquela aplicação específica. Se o processo tentar ultrapassar o teto estipulado, o próprio sistema entra em ação para conter o abuso, seja fazendo o programa esperar por sua vez na fila de processamento ou aplicando restrições severas. Esse controle fino impede que falhas em microsserviços secundários comprometam a estabilidade do servidor principal.

Como definir quotas rígidas de processamento no Docker

Para impor um limite rígido de utilização de processador em um container, utilizamos principalmente duas abordagens configuradas via linha de comando ou arquivos de orquestração: o controle de cotas temporais e a priorização relativa. O parâmetro --cpus, por exemplo, permite estipular exatamente quantos núcleos lógicos o container pode utilizar no máximo. Se configurarmos um limite de 1.5, a aplicação nunca conseguirá usar mais do que o equivalente a um núcleo e meio de CPU, mesmo que o servidor tenha dezenas de núcleos ociosos.

Por baixo do capô, essa limitação funciona dividindo o tempo de processamento em frações de milissegundos através das configurações conhecidas como cpu.cfs_quota_us e cpu.cfs_period_us. Na prática, o kernel obriga o container a pausar suas atividades assim que ele consome toda a fatia de tempo permitida dentro daquele período cíclico. Para validar se essas restrições estão funcionando e se o seu sistema não está sofrendo com outros problemas paralelos, vale a pena conferir como achar processos zumbis no Linux e liberar a CPU de forma eficiente.

Priorização flexível com cpu-shares para momentos de pico

Nem sempre o ideal é impor um teto rígido que impeça o container de usar mais hardware quando a máquina estiver completamente ociosa. Para cenários onde o objetivo principal é garantir prioridade sem desperdiçar capacidade, utilizamos o conceito de peso relativo através do parâmetro --cpu-shares. Por padrão, todo container recebe o valor de 1024, que funciona como um peso base padrão de distribuição de tempo de processamento entre os concorrentes.

Se você configurar um serviço crítico com 2048 cotas e um serviço secundário com 512, o kernel vai garantir que o primeiro receba o dobro de atenção do processador sempre que houver disputa por recursos. Na prática, isso significa que se a máquina estiver sobrando capacidade, o container de menor prioridade ainda poderá usar 100% da CPU livre, mas perderá espaço imediatamente assim que o serviço principal precisar de fôlego para atender a novas requisições.

Boas práticas de governança e monitoramento contínuo

Aplicar limites de cgroups sem monitoramento constante é como dirigir com os olhos vendados na estrada, pois você só percebe o problema quando o impacto já é catastrófico. É fundamental acompanhar métricas em tempo real para verificar se os containers estão esbarrando constantemente nos tetos de performance configurados. Além disso, quando o assunto envolve o dimensionamento correto de recursos, garantir que sua infraestrutura também esteja protegida contra esgotamentos repentinos de memória evita falhas catastróficas, conforme detalhamos ao analisar por que o Docker trava com OOM Killer e como auditar limites.

Em resumo, dominar o uso de cgroups e entender as limitações de hardware transforma a operação de ambientes Docker muito mais previsível e segura. Ao combinar pesos flexíveis para momentos de alta demanda e cotas rígidas para serviços que não podem extrapolar o orçamento, você garante um ecossistema equilibrado. Planeje suas políticas de recursos com base no comportamento real das suas aplicações e mantenha sempre uma camada de observabilidade ativa.