CodeOath
← All posts
Docker65 min total · 19 parts

Docker Fundamentals: Images, Containers, and Writing a Good Dockerfile

Contents — Part 18 of 19: Resource Limits
  1. 1.Overview
  2. 2.What Problem Docker Actually Solves
  3. 3.Image vs. Container
  4. 4.The Docker Engine's Moving Parts
  5. 5.Images Are Made of Layers, and Layers Are Cached
  6. 6.Dockerfile Instructions, One by One
  7. 7.CMD vs. ENTRYPOINT: The Instruction Everyone Mixes Up
  8. 8.Multi-Stage Builds
  9. 9..dockerignore and the Build Context
  10. 10.Choosing a Base Image
  11. 11.Networking Basics
  12. 12.Volumes, Bind Mounts, and tmpfs
  13. 13.Docker Compose: Running More Than One Container Together
  14. 14.Health Checks and Restart Policies
  15. 15.Environment-Specific Configuration
  16. 16.Security Basics
  17. 17.Debugging a Running Container
  18. 18.Resource Limits
  19. 19.Common Mistakes Worth Remembering
Part 18 of 19 · ~1 min

Resource Limits

Without limits, a single container can consume all of a host's CPU or memory, starving every other container (and the host itself) sharing that machine — cgroups (mentioned earlier) are what actually enforce whatever limits you set:

docker run --memory=512m --cpus=1.5 myapp

services:
  web:
    image: myapp
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.5"

A container that exceeds its memory limit is killed by the kernel's OOM killer (exit code 137, as mentioned above) rather than being throttled — memory limits are hard caps, not soft suggestions. CPU limits behave differently: a container over its CPU limit isn't killed, it's throttled — it simply gets scheduled less CPU time, which shows up as increased latency rather than a crash. This asymmetry matters when diagnosing production incidents: a memory-related crash is sudden and visible in exit codes, while a CPU throttling problem often just looks like unexplained slowness.

← Previous
Debugging a Running Container
Next →
Common Mistakes Worth Remembering