14.1.2.2 Production Resource Limits

Production resource limits explicitly constrain the CPU and memory a container can consume, preventing a single misbehaving or overloaded container from exhausting a host's shared resources and degrading every other workload running alongside it.

Setting Memory and CPU Limits

Compose, Swarm, and Kubernetes all support explicitly declaring these constraints for a service.

services:
  app:
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 256M

The limits values cap this service's maximum resource consumption; the reservations values guarantee a minimum amount is always available to it.

Why Limits Protect Other Workloads on a Shared Host

Without an explicit limit, a single container experiencing a memory leak or unexpected load spike could consume all of a host's available memory, starving every other container running on that same host.

docker stats

Monitoring actual resource usage against configured limits confirms a container isn't approaching (or exceeding) its intended boundary.

Determining Appropriate Limit Values

Limits set far too low risk the application itself being killed or throttled under normal operation; limits set far too high provide little actual protection — observing real usage under representative load informs an appropriate, deliberate choice.

docker stats --no-stream myapp

Reviewing actual memory and CPU usage under realistic load provides the data needed to set a limit that's both protective and not unnecessarily restrictive.

What Happens When a Container Exceeds Its Memory Limit

A container exceeding its configured memory limit is typically killed by the kernel's out-of-memory mechanism, an outcome worth understanding and monitoring for, rather than being unexpectedly surprised by.

docker inspect myapp --format '{{.State.OOMKilled}}'

Why Production Resource Limits Matter

Explicitly constraining each container's resource consumption is essential for protecting a shared host's overall stability, ensuring one workload's problem doesn't cascade into a broader outage affecting every other service running alongside it.