Skip to main content

cgroups v2 Cuotas de Recursos y OOM Watchdogs

Mecanismos del núcleo de Linux (Control Groups v2) para establecer límites de hardware estrictos en RAM, CPU, disco y número de procesos (PIDs) con el fin de proteger al host de ciclos de agentes colapsados.

1. Visión general del concepto y problema sistémico

Los agentes de IA autónomos son inherentemente impredecibles:

  • Un agente escribe una función recursiva para recorrer un grafo de archivos, olvida la condición de salida y comienza una asignación de memoria infinita.
  • En 30 segundos, el consumo de RAM salta de 200 MB a 32 GB.
  • En el host, se activa el mecanismo de emergencia de Linux Out-Of-Memory (OOM Killer), que, mediante un algoritmo heurístico impredecible, termina no solo con el agente colapsado, sino también con la base de datos PostgreSQL y el servidor web.

Control Groups v2 (cgroups v2) es la celda de ingeniería del núcleo de Linux. Permite asignar al proceso del agente límites estrictos: incluso si el agente intenta asignar un terabyte de memoria, el núcleo lo limitará forzosamente al límite asignado y finalizará cuidadosamente solo ese proceso aislado.

2. Taxonomía arquitectónica y modelo mental

┌─────────────────────────────────────────────────────────────┐
│                 CGROUPS V2 UNIFIED HIERARCHY                │
├─────────────────────────────────────────────────────────────┤
│ ROOT CONTROL GROUP (/sys/fs/cgroup)                         │
│ ├── system.slice (Servicios críticos del host: SSH, Systemd, UFW) │
│ │   ➔ Memoria garantizada y alta prioridad de CPU           │
│ └── agent-sandbox.slice (Contorno aislado del agente)       │
│     ├── memory.max = 1536M (Límite estricto de memoria)    │
│     ├── memory.high = 1200M (Límite suave: throttling)     │
│     ├── cpu.max = 100000 100000 (Máximo 1 núcleo completo)  │
│     ├── pids.max = 150 (Protección contra Fork Bomb)       │
│     └── io.weight = 100 (Baja prioridad de escritura en SSD)│
└─────────────────────────────────────────────────────────────┘

3. Pipeline técnico y mecánica interna

01. Protección del servidor host a través de systemd-run

Ejecutar un script de agente arriesgado directamente en un grupo de restricciones dedicado sin contenedor:

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

Si el script supera 1 GB de RAM, el núcleo reiniciará inmediatamente solo el servicio agent_worker.py, sin afectar a ningún otro proceso en el servidor.

02. Uso de PSI para gestión adaptativa de carga

Un demonio de monitoreo lee /proc/pressure/memory. Si el indicador de presión supera el 20%, el sistema automáticamente suspende la aceptación de nuevas tareas para los agentes hasta que los cálculos actuales se completen.

4. Errores comunes, trampas y seguridad

  • Bucle OOM (Ciclo infinito de reinicios): Si el límite de memoria se establece demasiado bajo (por ejemplo, 256 MB para una aplicación Node.js), el agente fallará y se reiniciará cada 10 segundos, saturando las colas.
  • Swap desactivado: Con la ausencia total de un archivo de Swap en el servidor, un repentino aumento de memoria provoca un SIGKILL inmediato. Se recomienda tener un pequeño zram o swapfile en un NVMe rápido para mitigar picos repentinos.

5. Estrategia de conclusión para el ingeniero de 2026

cgroups v2 es la base de la estabilidad de cualquier infraestructura que interactúe con código autónomo. Establecer cuotas de hardware estrictas garantiza que ningún error o alucinación de IA pueda comprometer la disponibilidad del servidor host.

/ Preguntas frecuentesSchema.org FAQPage

FAQ: cgroups v2 Cuotas de Recursos y OOM Watchdogs

cgroups v1 tenía jerarquías separadas e independientes para memoria, CPU y dispositivos de bloque, lo que resultaba en errores y la imposibilidad de un throttling preciso de entrada/salida (I/O). cgroups v2 utiliza una jerarquía unificada de procesos (Unified Hierarchy) y soporta la presión de memoria (Pressure Stall Information - PSI).
/ Enlaces internos
Todos los términos