How do you manage container resources (CPU and memory)?

Question

IT Interview Practice · Accepted Answer

By default, containers can use **unlimited host resources** — which risks one container starving others or crashing the host. Docker lets you set **resource limits** (CPU, memory) to control consumption, important for stability and fair resource sharing in production.

## The problem: unbounded resource use

```text
BY DEFAULT a container can consume ALL available host CPU and memory:
  → a buggy/busy container (memory leak, runaway loop) can starve other containers
    or crash the entire host (out of memory)
→ In production (multiple containers per host), LIMIT resources to isolate them.
```

## Setting memory and CPU limits

```bash
# memory limits
docker run -m 512m myapp              # hard limit: 512 MB (container killed if exceeded — OOM)
docker run -m 512m --memory-reservation 256m myapp   # soft limit + hard limit

# CPU limits
docker run --cpus="1.5" myapp         # limit to 1.5 CPU cores
docker run --cpu-shares=512 myapp     # relative weight (priority under contention)
```

```yaml
# in docker-compose.yml (or for orchestrators)
services:
  app:
    deploy:
      resources:
        limits:    { cpus: '1.5', memory: 512M }   # maximum
        reservations: { cpus: '0.5', memory: 256M } # guaranteed minimum
```

Memory limits (`-m`) cap usage (the container is **OOM-killed** if it exceeds the hard limit); CPU limits (`--cpus`) cap CPU usage. **Reservations** guarantee a minimum.

## Monitoring and tuning

```text
✓ docker stats → live CPU/memory usage per container (to right-size limits)
✓ Set limits based on the app's actual needs (measure, then add headroom)
✓ OOMKilled (in docker inspect) → the container hit its memory limit → raise it or fix a leak
✓ Orchestrators (Kubernetes) use requests/limits similarly — essential for scheduling
```

## Why it matters

Understanding container resource management is important for **running containers reliably in production**, so it's valuable operational knowledge.

The core issue — by default, **containers can consume all available host resources** — is a real risk: a single buggy or busy container (with a memory leak or runaway process) can **starve other containers or crash the entire host** (out of memory), making the host unstable.

Setting **resource limits** (memory and CPU) prevents this by **isolating containers' resource consumption**, ensuring one container can't take down others or the host — essential for stability when running multiple containers per host (the norm in production).

Understanding how to set **memory limits** (with the container being OOM-killed if it exceeds the hard limit) and **CPU limits**, plus **reservations** (guaranteeing minimums), is the practical mechanism for controlling and fairly sharing resources.

Knowing how to **monitor and tune** — using `docker stats` to observe actual usage and right-size limits, recognizing `OOMKilled` (a container hitting its memory limit) to diagnose issues — is important for setting appropriate limits based on real needs.

This also connects to orchestration: **Kubernetes uses similar resource requests/limits** that are essential for scheduling and stability, so understanding the concept transfers to orchestrated environments.

Since running multiple containers reliably requires preventing resource contention and runaway consumption, and since resource limits (memory and CPU caps, reservations, monitoring) are the mechanism for isolating containers and protecting host stability, understanding container resource management is valuable, practically-important knowledge for production container deployments — necessary for stable multi-container hosts and a concept that extends directly to orchestrated environments like Kubernetes, where resource specification is fundamental.

The problem: unbounded resource use

Setting memory and CPU limits

Monitoring and tuning

Why it matters

Related questions