Skip to content
Latchkey

O que é um limite de memória de cgroup? Tetos de memória de container explicados

Um limite de memória de cgroup é um teto de memória por container. Atinja-o e o kernel dá OOM-kill dentro daquele grupo - mesmo que o host tenha gigabytes livres.

Control groups (cgroups) são o recurso do Linux que limita quanto CPU, memória e I/O um grupo de processos pode usar. O limite de memória é o motivo pelo qual jobs de CI em container podem ficar sem memória enquanto a máquina subjacente parece ociosa.

O que é um cgroup

Um cgroup é um balde de processos gerenciado pelo kernel com limites de recursos anexados. Containers e muitos jobs de CI rodam dentro de um. O controlador de memória define um teto rígido no uso do grupo e o impõe independentemente da RAM total do host.

Por que seu job dá OOM com memória livre no host

Quando o uso de um cgroup atinge seu limite, o kernel dispara um OOM kill *restrito àquele cgroup* - ele mata um processo do grupo em vez de checar o host. Então uma máquina de 16 GB pode dar OOM-kill em um job limitado a 2 GB. A saída de free no nível do host é irrelevante para um job limitado por cgroup.

Como inspecionar e ajustar

  • Leia o limite do cgroup (por exemplo, memory.max no cgroup v2) dentro do job.
  • Compare o pico de RSS do seu processo com esse limite, não com a RAM do host.
  • Aumente o limite de memória do container/job, ou reduza o pico de uso para caber nele.
cgroup v2 memory ceiling
cat /sys/fs/cgroup/memory.max

Por que importa para tuning

Runtimes de linguagem que dimensionam o heap automaticamente pela RAM do host (JVMs mais antigas, alguns padrões do Node) podem superalocar muito além de um limite de cgroup e serem mortos. Torne o runtime cgroup-aware ou defina tetos de heap explícitos para que ele se dimensione pelo container, não pelo host.

Principais conclusões

  • Um limite de memória de cgroup limita um container/job independentemente da RAM do host.
  • Atingi-lo dispara um OOM kill restrito àquele cgroup → exit 137.
  • Memória livre no host não protege um job limitado por cgroup.
  • Torne os runtimes cgroup-aware ou defina tetos de heap explícitos para caber no limite.

Guias relacionados