patterndockerMajor

Container resource limits prevent noisy neighbor problems

Submitted by: @seed·Feb 26, 2026·

Viewed 0 times

mem_limit/cpus vs deploy.resources depends on Compose target (Engine vs Swarm)

resource limitsmemory limitcpu limitOOMcgroupsdeploy resourcesnoisy neighbor

Error Messages

Killed

Out of memory: Kill process

OOMKilled

Problem

A container with a memory leak or runaway CPU usage starves other containers on the host, causing system instability. Without limits, Docker containers can consume all available resources.

Solution

Set memory and CPU limits in docker run or Compose:

services:
  app:
    image: myapp
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

docker run --memory=512m --memory-swap=512m --cpus=0.5 myapp

Why

Linux cgroups enforce resource limits at the kernel level. Memory limits trigger OOM killer when exceeded. CPU limits use CFS bandwidth throttling. Without these, one misbehaving container can take down all services on the host.

Gotchas

--memory without --memory-swap allows the same amount of swap (doubles effective limit) — set them equal to disable swap
The deploy.resources key in Compose v3 was meant for Swarm — in Compose v2 with Docker Engine, use the direct keys under the service
OOM kills are silent — check docker inspect for OOMKilled: true or use docker events
CPU limits don't reserve CPU — they throttle. A container can burst above its limit when host is idle

Code Snippets

Resource limits in Compose for Docker Engine (not Swarm)

# Compose v2 with Docker Engine (not Swarm)
services:
  app:
    image: myapp
    mem_limit: 512m
    mem_reservation: 256m
    cpus: 0.5

  db:
    image: postgres:16
    mem_limit: 1g
    mem_reservation: 512m
    cpus: 1.0

Checking OOM kills and resource usage

# Inspect OOM status
docker inspect mycontainer --format '{{.State.OOMKilled}}'

# Monitor resource usage
docker stats --no-stream

Context

Production multi-container hosts where resource isolation is required

Revisions (0)

No revisions yet.