Skip to main content

Cgroups v2: Quotas de Recursos e Watchdogs OOM

PARA AGENTES DE IAChatGPTClaude

Mecanismos do kernel Linux (Control Groups v2) para estabelecer limites rígidos de hardware em RAM, CPU, disco e número de processos (PIDs), visando proteger o host contra ciclos de agentes travados.

1. Visão geral do conceito e o problema sistêmico

Agentes de IA autônomos são, por natureza, imprevisíveis:

  • Um agente escreve uma função recursiva para percorrer um grafo de arquivos, esquece a condição de saída e dispara uma alocação infinita de memória.
  • Em 30 segundos, o consumo de RAM salta de 200 MB para 32 GB.
  • No host, o mecanismo de emergência Linux Out-Of-Memory (OOM Killer) é acionado e, seguindo heurísticas imprevisíveis, mata não apenas o agente travado, mas também o banco de dados PostgreSQL principal e o servidor web.

Control Groups v2 (cgroups v2) funcionam como uma "jaula" de engenharia no kernel do Linux. Eles permitem definir limites rigorosos para o processo do agente: mesmo que o agente tente alocar um terabyte de memória, o kernel imporá o limite definido e encerrará graciosamente apenas esse processo isolado específico.

2. Taxonomia arquitetural e modelo mental

┌─────────────────────────────────────────────────────────────┐
│                 HIERARQUIA UNIFICADA CGROUPS V2             │
├─────────────────────────────────────────────────────────────┤
│ GRUPO DE CONTROLE RAIZ (/sys/fs/cgroup)                     │
│ ├── system.slice (Serviços críticos do host: SSH, Systemd, UFW) │
│ │   ➔ Memória garantida e alta prioridade de CPU           │
│ └── agent-sandbox.slice (Ambiente isolado do agente)        │
│     ├── memory.max = 1536M (Limite rígido de memória)      │
│     ├── memory.high = 1200M (Limite suave: throttling)     │
│     ├── cpu.max = 100000 100000 (Máximo de 1 núcleo completo) │
│     ├── pids.max = 150 (Proteção contra Fork Bomb)         │
│     └── io.weight = 100 (Baixa prioridade de escrita no SSD) │
└─────────────────────────────────────────────────────────────┘

3. Cenários práticos de engenharia em produção

01. Proteção do servidor host via systemd-run

Execução de scripts de agentes arriscados diretamente em um grupo de limitação dedicado, sem contêiner:

systemd-run --scope -p MemoryMax=1G -p CPUQuota=50% -p TasksMax=50 python agent_worker.py

Se o script exceder 1 GB de RAM, o kernel reiniciará imediatamente apenas o serviço agent_worker.py, sem afetar nenhum outro processo no servidor.

02. Uso de PSI para gerenciamento adaptativo de carga

Um daemon de monitoramento lê /proc/pressure/memory. Se o indicador de pressão ultrapassar 20%, o sistema pausa automaticamente a aceitação de novas tarefas para os agentes até que os cálculos atuais sejam concluídos.

4. Armadilhas comuns, erros típicos e segurança

  • Loops de OOM (Reinicialização infinita): Se o limite de memória for definido muito baixo (por exemplo, 256 MB para uma aplicação Node.js), o agente cairá e será reiniciado a cada 10 segundos, entupindo as filas.
  • Swap desativado: Na ausência total de arquivo Swap no servidor, um pico súbito de memória causa um SIGKILL imediato. Recomenda-se manter um pequeno zram ou swapfile em NVMe rápido para suavizar picos extremos.

5. Conclusão estratégica para engenheiros em 2026

O cgroups v2 é a base da estabilidade de qualquer infraestrutura que interaja com código autônomo. A imposição de cotas rígidas de hardware garante que nenhum erro ou alucinação de IA possa comprometer a disponibilidade do servidor host.

/ Perguntas FrequentesSchema.org FAQPage

FAQ: Cgroups v2: Quotas de Recursos e Watchdogs OOM

O cgroups v1 possuía hierarquias separadas e não relacionadas para memória, processador e dispositivos de bloco, o que levava a bugs e impossibilidade de throttling preciso de E/S (I/O). O cgroups v2 utiliza uma única hierarquia unificada de processos (Unified Hierarchy) e suporta pressão de memória (Pressure Stall Information - PSI).
/ Links internos
Todos os termos