Skip to content
zviz

Tuning cgroups v2 limits

Cap memory, PIDs, and CPU per container so a runaway or hostile workload stays contained.

Level: intermediateTime: 8 min

cgroups v2 is the last layer ZViz applies — once the process boundary exists, it caps what that process can consume. This guide covers the limits worth setting for untrusted work.

Why cgroups matter for hostile workloads

A workload you do not trust may try to exhaust the host: allocate all the memory, fork endlessly, or peg every CPU. Namespaces and seccomp do not stop resource exhaustion — cgroups v2 does. It is the difference between a fork bomb hitting a cap and a fork bomb taking down the host.

The limits to set

  • Memory — cap total memory so an allocator loop hits the limit instead of the host’s OOM killer at large.
  • PIDs — cap the process count so a fork bomb stops at the cgroup boundary.
  • CPU — bound CPU time so one container cannot starve its neighbours.

Set these to the smallest values the workload legitimately needs. As with the syscall policy, start tight and loosen only on a real failure.

Requirements

ZViz uses the cgroups v2 unified hierarchy. Confirm your host has it enabled — most current distributions default to v2. Combined with namespaces and the seccomp policy, cgroups complete the containment story: isolate what the workload sees, deny what it can call, and cap what it can consume.

Frequently Asked Questions

What happens when a workload hits its memory cap?

The cgroup memory controller enforces the limit — the workload is constrained rather than the host being exhausted. A fork bomb hits the PID cap the same way.

Do I need cgroups v2 specifically?

Yes. ZViz uses the cgroups v2 unified hierarchy. Your host must have cgroups v2 enabled; most modern distributions default to it.

Related

Run untrusted code with a smaller attack surface

ZViz is open source under Apache 2.0. Build it and point it at any OCI bundle.