Hello World 😁 💻

Na minha jornada para entender melhor o mundo da tecnologia e seus pilares, o tema que escolhi estudar e compartilhar hoje é o tal do cgroup.

O que é cgroup?

Quem é esse cara, afinal?

O termo vem de control group (grupo de controle) e, curiosamente, costuma ser escrito em minúsculo mesmo, seguindo a documentação oficial do kernel Linux.

De forma direta, ele resolve um problema bem concreto: controlar e isolar o uso de recursos do sistema entre processos.

O Linux sempre foi muito bom em rodar várias coisas ao mesmo tempo. O problema é que, por muito tempo, ele não tinha uma forma eficiente de dizer “até aqui você pode ir, daqui pra frente não”. Se um processo resolvesse consumir CPU ou memória demais, o resto do sistema acabava pagando o preço.

De onde isso veio?

O cgroup não surgiu como teoria bonita. Ele nasceu de necessidade prática dentro do Google, lá por 2006.

Na época, o nome era outro: Process Containers. Só que isso gerou confusão, pois parecia algo mais próximo do que hoje chamamos de containers completos. Para evitar esse ruído, o nome foi ajustado para control groups, que descreve melhor a ideia central.

O objetivo era simples: conseguir rodar vários tipos de carga em milhares de máquinas sem precisar separar tudo em servidores dedicados. Era uma questão direta de eficiência.

Alguns anos depois, em 2008, isso foi incorporado oficialmente ao kernel Linux.

E como isso evoluiu?

A primeira versão resolveu o problema, mas trouxe algumas limitações de design. Com o tempo, veio o cgroup v2, com uma proposta mais organizada e consistente.

Sem entrar muito fundo, a v2 melhora bastante a forma como os recursos são estruturados e gerenciados. Hoje, ela já é o padrão na maioria das distribuições modernas.

Entendendo na prática como cgroup opera

Eu pedi para o Gemini para me dar um exemplo do uso do cgroup e achei o exemplo dele super didático:

"Imagine que o seu servidor Linux é um escritório compartilhado e os processos são os funcionários. Sem cgroups, um único funcionário 'fominha' poderia beber todo o café e usar todo o Wi-Fi, deixando os outros parados. O cgroup é o gerente que define: Você só pode usar 10% do Wi-Fi e duas xícaras de café."

Representação em tirinha de um cenário sem cgroup e com cgroup.

Lidando com um processo "funcionário-fominha"

1. Cenário

Para sair um pouco da abstração, imagine um processo simples que começa a consumir CPU sem parar:

md5sum /dev/urandom

Comando no terminal.

Esse comando fica gerando dados indefinidamente e tende a usar o máximo de CPU que conseguir.

Comando escrito no terminal

Processo rodando no terminal

O processo é o primeiro da lista, com o PID 8397. Como podemos ver, ele está consumindo 100% da CPU.

2. Criando o Grupo de Controle

No Linux moderno (cgroup v2), tudo funciona através de pastas no diretório /sys/fs/cgroup. Vamos criar um grupo chamado limitado:

sudo mkdir /sys/fs/cgroup/limitado

Assim que você cria a pasta, o kernel Linux gera automaticamente vários arquivos de controle dentro dela.

Arquivos de controle dentro da pasta criada.

3. Definindo o Limite

Queremos que esse grupo use, no máximo, 20% de um núcleo de CPU. O arquivo cpu.max é o responsável por essa delimitação. Ele aceita dois valores: a cota (quota) e o período (period) em microssegundos. Então usaremos o seguinte comando:

echo "20000 100000" | sudo tee /sys/fs/cgroup/limitado/cpu.max

20.000 de 100.000 microssegundos = 20% de CPU.

Criação da pasta "limitado" e o comando para limitar o uso do grupo na CPU.

4. Colocando o Processo na "Prisão"

Agora, basta mover o ID do processo (PID) do nosso comando md5sum para o arquivo cgroup.procs desse grupo. No nosso exemplo, o PID é 8397:

sudo echo 8397 | sudo tee /sys/fs/cgroup/limitado/cgroup.procs

Movendo o processo para o grupo "limitado".

Processo movido para o grupo "limitado".

O Resultado: Instantaneamente, se você olhar o top ou htop, verá que aquele processo que antes usava 100% agora não consegue ultrapassar a barreira dos 20%.

Processo com no máximo 20% de uso na CPU.

E como fica a performance do processo limitado?

Estudando cgroup me bateu uma dúvida: se um processo está usando muitos recursos, isso não significa que ele precisa desses recursos? Limitá-los não afetaria a performance desse processo?

A resposta que encontrei é: Sim, limitar recursos impacta diretamente o tempo de execução.

Se antes um processo levava 10 segundos usando toda a CPU, ao restringir para 20% ele naturalmente vai demorar mais.

O ponto é que nem todo processo que usa muito recurso realmente precisa disso de forma urgente. Muitos simplesmente usam porque está disponível.

E aí entra a questão principal: proteger o sistema como um todo.

O outro lado da moeda

Sem algum tipo de controle, um processo mais pesado pode acabar prejudicando outros que são mais sensíveis, como um servidor web ou uma interface que precisa responder rápido.

Esse cenário costuma ser descrito como starvation: um processo fica “sem espaço” para rodar porque outro está ocupando tudo.

Quando você limita ou organiza melhor o uso de recursos, pode até reduzir a vazão de um processo específico, mas melhora a resposta geral do sistema.

Nem sempre limitar é a melhor escolha

Existem situações em que impor um limite rígido pode causar mais problema do que solução.

Bancos de dados, sistemas críticos ou aplicações sensíveis a tempo podem precisar de um comportamento mais flexível. Nesses casos, em vez de limitar diretamente, faz mais sentido trabalhar com prioridade.

Ou seja, o processo pode usar bastante recurso se estiver sozinho, mas perde espaço quando algo mais importante precisa rodar.

Quando a limitação é perigosa?

Existem casos onde limitar o recurso pode causar falhas críticas, e não apenas lentidão:

Onde isso aparece no mundo real?

Grande parte das tecnologias modernas de infraestrutura depende diretamente disso.

Containers, por exemplo, só conseguem funcionar de forma previsível porque existe um mecanismo por trás garantindo isolamento de recursos, e esse mecanismo passa pelos cgroups.

Conclusão

No fim das contas, o cgroup não é algo “visível” no dia a dia, mas está por trás de muita coisa que a gente usa.

Ele resolve um problema simples de entender, mas difícil de gerenciar na prática: garantir que vários processos consigam coexistir sem que um atrapalhe o outro.

É uma daquelas peças do sistema que você quase não percebe , até o momento em que faz falta.

Gostei muito de ter explorado esse recurso do kernel Linux e ver como ele funciona. Espero que tenham gostado também e que esse artigo tenha sido útil de alguma forma.

Obrigada pela atenção e até breve! 😁

Laryssa Ramos.