Runtime Performance

CPU and Memory Controls

Containers share the host kernel, so limits are cgroup settings you must set yourself:

docker run -d --name api \
  --cpus 1.5 \
  --memory 512m --memory-swap 512m \
  --cpu-shares 512 \
  registry.example.com/api:1.4

--cpus throttles to 1.5 cores on average; --memory is a hard ceiling — exceeding it triggers the OOM killer instead of letting one service evict the host's page cache. --memory-swap bounds RAM plus swap together; setting it equal to memory disables swap for the container. --cpu-shares only matters under contention: it weights fair-share CPU, it does not cap usage.

Processes, Descriptors, and I/O

docker run -d --pids-limit 256 \
  --ulimit nofile=65536:65536 \
  --device-read-bps /dev/sda: 10mb \
  myapp:1.4

--pids-limit caps the PID namespace so a fork bomb dies inside the container instead of exhausting host PIDs. nofile raises open-file ceilings for proxies and Node servers that otherwise hit EMFILE under load. On cgroup v2, I/O is shaped with --storage-opt or io.max per device; --device-read-bps caps throughput for a bound device. Verify with cat /sys/fs/cgroup/... inside the container or docker stats.

Network, Logging, and Pitfalls

Network mode. Bridge adds NAT overhead per connection; --network host removes it but exposes every port and skips Docker's port mapping — a throughput win with a blast-radius cost.

Logs fill disks. The default json-file driver grows without bound; cap it:

docker run --log-opt max-size=10m --log-opt max-file=5 myapp:1.4

Swap. Unlimited swap hides memory leaks until the host thrashes; bound it.

Interview: size a container from observed docker stats numbers, state which limit prevents which failure (OOM, EMFILE, fork bomb, disk-full), and defend any limit you would leave unset.