Lesson 13 of 30

Resource Limits & cgroups

Q: A production container is exiting randomly under load with no application error in the logs, exit code 137. How would you determine whether this is a memory limit issue, and what would you do about it?

A strong answer covers: Explain that exit code 137 means SIGKILL, and that this alone doesn't confirm the cause — check docker inspect's OOMKilled field specifically; Explain the mechanism: cgroups enforce a hard memory ceiling, and the kernel's OOM killer sends SIGKILL the moment usage crosses it, with no graceful degradation; Propose using docker stats to observe live usage against the configured limit as corroborating evidence; Propose a fix — raise the memory limit if the app's real need is legitimate, or investigate a possible leak if usage keeps climbing rather than plateauing.

`--memory` and `--cpus` aren't Docker features exactly — they're a thin layer over a Linux kernel mechanism, and knowing that mechanism is what tells you why a memory-limited container dies instead of slowing down.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A container hits its `--cpus=1.5` limit under heavy load. What actually happens?

The container is throttled and runs slower, but keeps runningThe container is OOM-killed the same way it would be for exceeding a memory limitDocker automatically raises the limit temporarily to avoid degrading performance

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Resource Limits & cgroups

What interviewers actually ask about this, and what a strong answer has to cover.

A production container is exiting randomly under load with no application error in the logs, exit code 137. How would you determine whether this is a memory limit issue, and what would you do about it?

A strong answer covers

Explain that exit code 137 means SIGKILL, and that this alone doesn't confirm the cause — check docker inspect's OOMKilled field specifically
Explain the mechanism: cgroups enforce a hard memory ceiling, and the kernel's OOM killer sends SIGKILL the moment usage crosses it, with no graceful degradation
Propose using docker stats to observe live usage against the configured limit as corroborating evidence
Propose a fix — raise the memory limit if the app's real need is legitimate, or investigate a possible leak if usage keeps climbing rather than plateauing

Likely follow-ups

Would raising the CPU limit instead of the memory limit ever cause the same symptom? Why or why not?
If the application is a JVM or Node process, what else besides the container's own memory limit might need to change together with it?

Practice these with the AI interviewer →

The plain-language idea

A container isn't a VM with its own dedicated slice of hardware — by default, every container on a host competes for the same CPU and memory as every other process on that machine, with no boundaries at all. cgroups (control groups), a Linux kernel feature, are what actually enforce boundaries when you set --memory or --cpus. Docker's flags are a convenient interface; the kernel's cgroup subsystem is what does the accounting and enforcement underneath.

CPU and memory limits behave very differently once you understand what cgroups actually do with each:

CPU limits are soft. --cpus=1.5 tells the kernel scheduler to throttle the container's processes so they can't use more than 1.5 cores' worth of time, averaged over a period. Exceed it and the container just gets slower — throttled, not killed.
Memory limits are hard. --memory=512m sets a ceiling the kernel actively enforces. There's no "slow down" option for memory the way there is for CPU time — memory is either available or it isn't. Cross the limit, and the Linux kernel's OOM killer sends SIGKILL to a process inside the container to bring usage back under the ceiling.

See it in a real thing: a memory limit that looks like a crash

docker run --memory=256m --memory-swap=256m myapp:latest
docker inspect myapp --format '{{.State.OOMKilled}} {{.State.ExitCode}}'
# true 137

If myapp legitimately needs 400MB under load, it doesn't degrade gracefully at the 256MB ceiling — the kernel's OOM killer picks a process inside the container's cgroup and kills it outright, the moment usage crosses the line. From the outside this looks exactly like an application crash: the container exits, exit code 137 (128 + SIGKILL's signal number 9), no graceful shutdown, no log line explaining why. docker inspect's OOMKilled: true field is the actual tell — without checking it, this is very easy to misdiagnose as an application bug rather than a limit set too low for what the app actually needs.

What people usually miss

Watch out

No limits at all means one runaway container can starve every other container on the host. Without --memory/--cpus, a memory leak or infinite loop in one container competes for the entire host's resources against every other container — there's no default isolation of "how much" a container may use, only isolation of what it can see (namespaces).
CPU throttling and memory OOM-killing are different severities of the same underlying enforcement. A CPU-starved container degrades (slower responses, higher latency) while staying alive; a memory-starved container dies outright — this asymmetry is exactly why memory limits need more conservative headroom than CPU limits, not the same safety margin.
docker stats shows live usage against the configured limit, and is the fastest way to confirm "is this container actually being throttled or OOM-killed" before diving into docker inspect for the postmortem detail.
Setting a memory limit without also thinking about the application's own memory behavior (e.g. a language runtime's heap size) can OOM-kill a process that would've been fine with slightly different internal tuning — a container limit and, say, a JVM's -Xmx or Node's --max-old-space-size need to agree with each other, not just be set independently.

Why this matters in interviews

"A container keeps crashing under load with no error message — how would you investigate?" is a real production-debugging question, and naming cgroups, the OOM killer, exit code 137, and docker inspect's OOMKilled field precisely is what separates a candidate who's actually hit this in production from one guessing at "maybe it's a bug in the code." It's also the concrete mechanism behind the debugging lesson's "resource limits cause a specific, recognizable failure mode" point in this track.