Docker travando por falta de memória? Como ajustar limites e oom-kill

Por que o Docker consome toda a memória do servidor?

Quando você executa uma aplicação isolada dentro de um container Docker, ela enxerga por padrão toda a memória RAM física disponível na máquina hospedeira (o host). Na prática, isso significa que se a sua aplicação sofrer um pico de uso ou possuir um vazamento de memória silencioso, ela continuará sugando gigabytes até esgotar completamente os recursos do servidor. Para entender como o kernel do Linux gerencia essa disputa por hardware, vale conferir as bases explicadas em nosso artigo sobre como limitar recursos de containers com cgroups no Linux, que detalha o isolamento a fundo.

Sem uma cerca eletrônica impedindo a passagem, o processo descontrolado engole a memória livre até que o sistema operacional precise tomar uma atitude drástica para não congelar de vez. Essa falta de contenção é o principal motivo pelo qual servidores de homelab ou ambientes de produção caem misteriosamente durante a madrugada, deixando serviços fora do ar sem deixar rastros claros nos logs da própria aplicação afetada.

O papel dos cgroups e dos limites de RAM

Os cgroups (grupos de controle) são um recurso nativo do kernel do Linux que permite repartir, priorizar e limitar o uso de hardware como CPU, memória e disco entre vários processos. Quando aplicados ao ecossistema de containers, eles funcionam como uma balança rigorosa que impede qualquer software de ultrapassar a cota que lhe foi legitimamente atribuída pelo administrador do sistema.

Na prática, configurar esses limites evita que um banco de dados mal dimensionado ou uma ferramenta pesada de automação paralise serviços críticos rodando na mesma máquina. Essa organização estrutural é essencial para manter a estabilidade de servidores dedicados a múltiplos serviços, especialmente quando combinamos o Docker com ferramentas úteis como o Dozzle para logs ou painéis de gerenciamento centralizado.

Como configurar limites de memória no Docker Compose

Para colocar essa proteção em prática, a melhor abordagem é definir restrições diretamente nos arquivos de configuração do Docker Compose, garantindo que o container nasça com regras rígidas de consumo. O exemplo a seguir demonstra como impor um teto máximo de memória e uma reserva para evitar que o container seja sufocado na inicialização:

version: '3.8'
services:
  app:
    image: nginx:latest
    deploy:
      resources:
        limits:
          memory: 512M
        reservations:
          memory: 256M

Com essa configuração simples, a aplicação nunca conseguirá ultrapassar quinhentos e doze megabytes de RAM, protegendo o restante da infraestrutura contra picos inesperados de uso. Caso o processo precise de mais espaço do que o permitido, o mecanismo de segurança entra em ação para decidir o destino do container afetado.

Entendendo o comportamento do oom-kill em containers

O OOM Killer (Out-Of-Memory Killer) é um componente implacável do kernel Linux cuja função é sacrificar processos famintos para salvar o sistema operacional de um travamento total. Quando um container atinge o limite máximo de memória estipulado, o OOM Killer pode encerrar o processo principal instantaneamente, resultando na queda abrupta do container com o código de saída 137.

Para evitar surpresas desagradáveis, é possível configurar o comportamento do OOM através da flag --oom-kill-disable, embora essa prática exija cautela extrema em ambientes de produção. Desativar o encerramento automático significa que o container ficará travado aguardando liberação de espaço, o que pode congelar requisições pendentes e travar threads inteiras da sua aplicação.

Boas práticas para monitorar e evitar surpresas

Manter aplicações rodando de forma saudável exige visibilidade constante sobre o consumo real de hardware, permitindo ajustes finos antes que os limites causem interrupções indesejadas. Ferramentas leves de monitoramento ajudam a identificar gargalos operacionais, complementando análises de desempenho como aquelas vistas quando investigamos se há um disco lento no Linux e como achar gargalos de E/S com iostat para otimizar o subsistema de armazenamento.

Acompanhar métricas de uso de memória e CPU por meio de dashboards visuais transforma a administração de servidores em uma tarefa previsível e segura. Com os limites de cgroups ajustados e o comportamento do OOM compreendido, sua infraestrutura ganha a resiliência necessária para absorver cargas intensas sem quedas catastróficas. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como testar cristal oscilador na placa com multímetro.

Conclusão

Controlar o consumo de memória no Docker deixou de ser um luxo opcional e passou a ser um requisito fundamental para a estabilidade de qualquer infraestrutura moderna de TI. Ao dominar o uso de cgroups, configurar limites adequados no Docker Compose e entender a atuação do OOM Killer, você elimina falhas silenciosas e protege o host contra travamentos inesperados.

Implementar essas defesas garante que seus serviços rodem com previsibilidade, facilitando o diagnóstico de problemas e elevando o nível de maturidade operacional do seu ambiente de homelab ou produção.