docker statsLive CPU, memory, network and I/O per container
docker stats shows a live table of resource use for each running container: CPU %, memory used against its limit, network and block I/O, and process count. It's top for containers, and the quickest way to find which one is eating the host.
docker stats [OPTIONS] [CONTAINER...]You want a quick picture of what every container on this host is using right now.
docker statsStream resource usage for running containers, refreshing about once a second.
For each container the CLI opens GET /containers/<id>/stats, and dockerd samples the container's cgroup files about once a second. CPU % is the change in the cgroup's CPU time divided by the change in total system CPU time, times the number of CPUs, so 200% means two full cores. MEM USAGE is memory.current minus inactive file cache (page cache the kernel can drop), and LIMIT is memory.max, or the host's RAM if there's no -m. NET I/O comes from the interfaces in the container's network namespace, BLOCK I/O from io.stat, and PIDS from pids.current, counting threads too. Because CPU needs two samples, --no-stream takes about two seconds. The numbers are the same ones the kernel uses to OOM-kill and throttle the container.
--no-streamOne snapshot, then exit-a, --allInclude stopped containers (shown with zeros)--format TEMPLATEColumns: .Name .CPUPerc .MemUsage .MemPerc .NetIO .BlockIO .PIDs--no-truncDon't truncate container IDsdocker top CONTAINERThe processes inside one container (companion command)docker system dfDisk use by images, containers, volumes and cacheReading 150% CPU as 'over the limit'CPU % is relative to one core; 150% means one and a half cores busy. It's only a problem relative to --cpus or the host's core count.
Compare with --cpus (docker inspect -f '{{.HostConfig.NanoCpus}}') and nprocComparing docker stats memory with free or top inside the containerInside, tools read /proc/meminfo, which shows the host's memory, not the cgroup's limit or usage.
Trust docker stats, or read /sys/fs/cgroup/memory.current inside the containerRunning containers without -m and relying on docker stats to notice problemsBy the time you look, the host may already be in a global OOM state.
Set -m (and --cpus) on every container; use stats to tune themTry these on a Linux machine of your own. Each task has a hint and a solution.
Read the api container's memory limit from cgroup v2 inside it, then read your own shell's memory use and limit on this machine.
Write a docker command that prints, without headers, the name and CPU % of every running container, highest CPU first.
Read this row and say what's wrong: 'worker 0.40% 1.92GiB / 15.62GiB 12.29% ... PIDS 4096'.
docker statsLive CPU, memory, network and I/O per container
docker stats shows a live table of resource use for each running container: CPU %, memory used against its limit, network and block I/O, and process count. It's top for containers, and the quickest way to find which one is eating the host.
docker stats [OPTIONS] [CONTAINER...]You want a quick picture of what every container on this host is using right now.
docker statsStream resource usage for running containers, refreshing about once a second.
For each container the CLI opens GET /containers/<id>/stats, and dockerd samples the container's cgroup files about once a second. CPU % is the change in the cgroup's CPU time divided by the change in total system CPU time, times the number of CPUs, so 200% means two full cores. MEM USAGE is memory.current minus inactive file cache (page cache the kernel can drop), and LIMIT is memory.max, or the host's RAM if there's no -m. NET I/O comes from the interfaces in the container's network namespace, BLOCK I/O from io.stat, and PIDS from pids.current, counting threads too. Because CPU needs two samples, --no-stream takes about two seconds. The numbers are the same ones the kernel uses to OOM-kill and throttle the container.
--no-streamOne snapshot, then exit-a, --allInclude stopped containers (shown with zeros)--format TEMPLATEColumns: .Name .CPUPerc .MemUsage .MemPerc .NetIO .BlockIO .PIDs--no-truncDon't truncate container IDsdocker top CONTAINERThe processes inside one container (companion command)docker system dfDisk use by images, containers, volumes and cacheReading 150% CPU as 'over the limit'CPU % is relative to one core; 150% means one and a half cores busy. It's only a problem relative to --cpus or the host's core count.
Compare with --cpus (docker inspect -f '{{.HostConfig.NanoCpus}}') and nprocComparing docker stats memory with free or top inside the containerInside, tools read /proc/meminfo, which shows the host's memory, not the cgroup's limit or usage.
Trust docker stats, or read /sys/fs/cgroup/memory.current inside the containerRunning containers without -m and relying on docker stats to notice problemsBy the time you look, the host may already be in a global OOM state.
Set -m (and --cpus) on every container; use stats to tune themTry these on a Linux machine of your own. Each task has a hint and a solution.
Read the api container's memory limit from cgroup v2 inside it, then read your own shell's memory use and limit on this machine.
Write a docker command that prints, without headers, the name and CPU % of every running container, highest CPU first.
Read this row and say what's wrong: 'worker 0.40% 1.92GiB / 15.62GiB 12.29% ... PIDS 4096'.