Hello World 😁 💻

Na minha jornada para entender melhor o mundo da tecnologia e seus pilares, o tema que me propus a estudar e compartilhar hoje por aqui é o cgroup.

Quem seria esse ser simpático, esse tal de cgroup?

"cgroup significa control group (grupo de controle) e nunca é escrito com inicial maiúscula (palavras oficiais da documentação do The Linux Kernel )".

É um recurso importantíssimo do kernel Linux, criado para resolver um problema muito prático: controlar e isolar o consumo de recursos do sistema entre diferentes processos. Antes dele, o Linux era muito bom em multitarefa, mas ruim em impor limites precisos. Se um processo começasse a consumir CPU ou memória demais, poderia prejudicar o sistema inteiro.

Como a cegonha da tecnologia trouxe esse ser ao mundo?

O cgroup não nasceu de uma ideia acadêmica, mas de uma necessidade real de engenharia dentro do Google em 2006. Naquela época, ele foi batizado de "Process Containers". Mas houve debate na comunidade sobre esse nome e então ele foi alterado para: "Control Groups" (cgroups), porque o objetivo não era criar containers completos, mas controlar recursos de grupos de processos.

O motivo principal era que o Google precisava rodar suas buscas, e-mails e vídeos em milhares de servidores, mas não queria dedicar um servidor inteiro para cada tarefa pequena. Isso seria um desperdício imenso de dinheiro e energia. Então depois de desenvolverem a tecnologia, os engenheiros do Google propuseram ao kernel Linux a integração desse novo recurso, que foi oficializado em 2008.

Diferentes versões do cgroup

Os Control Groups (cgroups) do Linux passaram por uma grande reformulação. A versão original (v1) resolveu o problema imediato. A v2 tentou corrigir problemas estruturais do design inicial, focando em escalabilidade organizacional, governança de recursos, delegação segura e modelagem consistente.

O Docker e outros runtimes começaram usando v1. Hoje, a maioria das distribuições modernas usa v2 por padrão como Fedora, Debian (recentes) e Ubuntu (recentes).

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"

Imagine que você tem um script que processa vídeos ou minera dados e ele está consumindo 100% da CPU, travando o resto do sistema.

1. O Cenário

Como exemplo, iremos executar um comando que estressa a CPU:

md5sum /dev/urandom

Esse comando tenta calcular hashes infinitamente, usando toda a CPU disponível.

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, interfere diretamente na performance. Se um processo precisa de 100% da CPU para terminar uma tarefa em 10 segundos e você o limita a 20%, ele agora levará 50 segundos para concluir.

Mas eis a lógica por trás de "atrapalhar" o processo propositalmente:

1. Necessidade vs. Ganância

Nem sempre um processo usa muito recurso porque "precisa" no sentido de ser vital, mas sim porque ele é programado para ser ganancioso. Ele vai usar tudo o que puder, mesmo que isso não seja necessário para a tarefa em questão. Por exemplo:

• Compilação de código ou renderização: Se houver CPU disponível, eles vão usar tudo para acabar logo.
• Processos de Background: Um indexador de arquivos ou um backup não precisa terminar em 2 segundos se isso fizer o seu mouse travar ou seu vídeo no YouTube travar.

2. O conceito de "Starvation" (Inanição)

O cgroup não existe para ajudar o processo limitado, mas para proteger o resto do sistema. Se o seu processo de processamento de imagem usar 100% da CPU, o processo do Servidor Web (que entrega o site para o seu cliente) pode sofrer "starvation". Ele não consegue tempo de processamento para responder a um simples clique, resultando em lentidão ou erro de timeout.

3. Latência vs. Throughput

Existem dois tipos de performance:

• Throughput (Vazão): O quanto de trabalho o processo faz em uma hora. O cgroup diminui isso.
• Latência (Resposta): O quão rápido o sistema responde a um comando. O cgroup melhora isso para os outros processos.

Quando a limitação é perigosa?

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

Priorizar em vez de limitar

No cgroup, você não precisa apenas colocar um "muro" (limite fixo). Você pode usar Shares (pesos).

Em vez de dizer "Use no máximo 20%", você diz: "Se todo mundo quiser CPU ao mesmo tempo, você tem prioridade baixa".

Se o servidor estiver ocioso, o processo pode usar 100%. Mas, assim que um processo importante acordar, o cgroup "espreme" o processo fominha para o canto dele.

(Pretendo fazer um artigo explorando melhor esse recurso do cgroup.)

Conclusão

Em resumo, o cgroup é uma ferramenta poderosa para garantir que um processo não "coma" todos os recursos do sistema, protegendo a estabilidade e a performance geral. Ele é essencial para ambientes de produção, onde múltiplos processos e serviços precisam coexistir de forma harmoniosa.

Espero que esse artigo tenha sido útil para entender o que é o cgroup, como ele surgiu e como ele funciona na prática. Gostei muito de estudar esse recurso do kernel Linux e certamente pretendo explorar mais a fundo suas funcionalidades em artigos futuros.

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

Laryssa Ramos.