Servidor sem memória? Como isolar processos com cgroups no Linux

O perigo silencioso de processos sem limites de hardware

Quando uma aplicação entra em loop ou sofre com vazamentos de memória, ela começa a consumir cada vez mais recursos da máquina. Em questão de minutos, a memória RAM se esgota, o sistema começa a usar o espaço de troca no disco e a performance despenca até a máquina travar completamente. Em ambientes de produção, esse comportamento destrutivo pode derrubar múltiplos serviços críticos hospedados no mesmo servidor. Para evitar que um único software comprometa toda a infraestrutura, os administradores de sistemas precisam impor barreiras rígidas de uso de hardware.

Uma das ferramentas mais poderosas para resolver esse problema no kernel do Linux é o cgroups, abreviação para control groups. Trata-se de um recurso nativo que restringe, contabiliza e isola o uso de recursos como processador, memória e disco de qualquer conjunto de processos. Na prática, ele funciona como um guarda de trânsito rigoroso que impede que uma aplicação gaste mais do que a sua cota autorizada. Quando combinamos esse isolamento com boas práticas operadas em ambientes conteinerizados, ganhamos a mesma previsibilidade de carga que observamos quando um container trava no boot e precisamos ler logs do systemd no Docker para entender a falha.

Como funcionam os grupos de controle no kernel Linux

Por baixo do capô, o cgroups organiza os processos em uma árvore hierárquica dentro do sistema de arquivos virtual do kernel, localizado tipicamente no diretório sys/fs/cgroup. Cada pasta nessa estrutura representa um grupo com regras específicas de consumo. Se você mover um processo para dentro de uma dessas pastas, o kernel automaticamente passa a aplicar as restrições definidas ali. Essa arquitetura modular garante que diferentes serviços rodem na mesma máquina física sem disputar agressivamente pelos mesmos ciclos de processamento ou blocos de memória livre.

A versão moderna do sistema, conhecida como cgroups v2, unificou o gerenciamento de recursos para que diferentes subsistemas trabalhem em conjunto de forma muito mais coesa. Antigamente, na versão anterior, cada recurso como CPU e memória possuía árvores separadas, o que dificultava o controle integrado. Hoje, com a v2, temos um modelo unificado que simplifica drasticamente a auditoria e a aplicação de políticas de segurança. Essa evolução estrutural beneficia diretamente arquiteturas complexas que dependem de alta resiliência, assim como ocorre quando monitoramos a latência de rede no Kubernetes usando eBPF para garantir que o tráfego flua sem gargalos ocultos.

Prática: limitando o consumo de memória RAM passo a passo

Para colocar a mão na massa e criar um grupo de controle dedicado a limitar a memória de um script pesado, vamos utilizar a interface padrão do cgroups v2. O primeiro passo consiste em criar um novo diretório dentro da estrutura do sistema de arquivos virtual onde as políticas serão aplicadas. Abra o terminal com privilégios administrativos e execute o comando abaixo para criar o grupo chamado limitador.

sudo mkdir /sys/fs/cgroup/limitador

Em seguida, precisamos definir o teto máximo de memória que os processos inseridos neste grupo poderão utilizar. Vamos estabelecer um limite estrito de quinhentos megabytes gravando o valor correspondente em bytes no arquivo de controle de memória. O comando abaixo configura essa restrição de forma imediata no kernel.

echo