r/docker • u/UnidentifiedSID • 7d ago
3200% CPU available
I’m running Docker on Debian and Ubuntu. After years, I tried Docker Desktop on Windows. Why does it show 15.65% / 3200% (32 CPUs available)? Why does it count 1 CPU/thread as 100%?
13
u/itomeshi 7d ago
That's the convention for most OSes, and for docker it's quite important. Linux was doing that under the hood as well (anything that didn't have separate processes could go above '100%' CPU.
When scheduling VMs, pods or containers, you typically shape the limits to the load while letting you be cognizant of the host's limitations.
As an example, lets say I have an nginx container. NGINX is multithreaded and pretty predictable; As a result, it's not a stretch to give it like a quarter core minimum and half a core maximum if I was on a raspberry pi:
services:
web-app:
image: nginx:alpine
deploy:
resources:
limits:
cpus: '0.50' # Maximum limit: Container can use at most 50% of a single CPU core
memory: 512M # Maximum memory limit
reservations:
cpus: '0.25' # Guaranteed allocation: Reserves 25% of a core for this container
memory: 256M # Guaranteed memory reservation
The problem with 100% = 32 cores @ 100% means that your scaling isn't clear. If that was the case, '0.50' would be 16 cores on your 32 core box and 2 cores on a quad-core pi.
There is an argument that it's still a bit misleading - not all cores are created equally - but ultimately, this standard exists to make it easier to compare.
There are other issues with 100% = all 100% as well. It's an over-simplification that can hurt you. Let's say you have a highly single threaded application. Look at 'overall' load and seeing 5% doesn't look like it's CPU-bound, but it is.
1
u/AsYouAnswered 7d ago
I get what you're saying, but it's still misleading to report overall system utilization as a percentage of a number larger than 100. Each core is 0-100%, the overall utilization should represent the mean of all the cores. 5% overall utilization when a single threaded application is pegged is fine. That means you can still load up 19 more cores worth of total system utilization. One core will still show 100%, and the process will still show 100%, and any given single process with threads can still show over 100%, meaning that it's utilizing more than 100% of a single core, but the overall system utilization should still be a percentage of total cpu resources used.
Imagine for a moment that we represented RAM as percentage of a DIMM that's being utilized. If you had 16x 8GiB DIMMs, and your system showed one process as using 130% and another as using 580%, and the total utilization was 770%(other processes using 60%), that would get confusing, fast, wouldn't it? We just report that as 48% utilization and we understand that we can allocate more.
3
u/BrilliantLopsided135 7d ago
It's that way because they mean different things the percent is way more nuanced than that. Anyway as for ram... let me introduce you to virtual memory, go ahead check how much you have allocated.
2
u/itomeshi 7d ago
CPU measurement is always flaky b/c of singlethreaded vs. multithreaded vs. multiprocess, core IPC and clock differences, cache load, NUMA nodes, SMT/HT, etc. It's not that a single overall utilization metric is useless, just that it obscures too much for some use cases. In an ideal world, you get both, and you have enough UI space for that. That is what simple system monitors do, but again, the oversimplification has downsides, and Docker specifically is a more technically-oriented tool. There, you communicate the most useful part - and in virtualization, a core being '1' and equal to 100% (1.00) wins.
Going back to the Docker Desktop example from OP: Let's say I want to set a limit, and we'll assume the app is multithreaded or multiprocess. If I show 0.5% used (roughly 16%/3200%), then I have to figure out what my limit should be. If I want to limit it to about 1 core, I need to math out 100/32 = 3.3%. And if the host ever changes - I move a docker compose stack to a different machine, or I upgrade my CPU? Suddenly 3.3% might be 2 cores (on a 64-core box).
It's not a perfect system - there's a fair argument that core pinning/scheduling is a far more precise system, but it's also a massive pain in the ass. There's a fair argument that on a normal consumer desktop, these distinctions aren't meaningful, because we're not setting limits or trying to manage per-app load precisely. CPU usage is also spikey, and utilization is often constrained by memory/disk/network bandwidth. But for this job? It has advantages, in that it lets me or an algorithm do predictable planning without knowing the running system's architecture.
RAM is different because to the OS, the memory is a single pool. The actual chip or DIMM distribution doesn't get managed because the differences are generally not meaningful (in theory, you could hyperoptimize to balance usage between dual channels, but that's more trouble than it's worth).
1
u/KittensInc 6d ago
No, because a single-threaded program can only use up to 100% of one core. This means a machine with a mean CPU usage of 3% can still be CPU-limited! One core is working its balls off while the other 31 are at idle, but you wouldn't be able to tell.
Memory is a completely different story because it is just (mostly) one giant pool and any process can make use of all of it, if it wants to.
→ More replies (1)
5
u/agowa338 7d ago
Docker counts like linux. 1 CPU fully utilized is 100%. 2 CPUs fully utilized is 200% and so on.
So with 32 CPUs it's 3200%
1
u/No_Cattle_9565 7d ago
Because a container can use less than a full cpu (for example it gets half the time of a single core which would be 50%)
1
u/Annh1234 7d ago
Each thread ( not cpu or cpu core ) is seen as a cpu core by the system, and each of those threads get data to process, and can only process it sequenceally. So if a thread is busy for half a second let's say, it will show 50% cpu usage on that thread, and 0% to the rest.
If you have a stupid script that needs each thread to count to X before it's done, one thread could be at 100% still counting, the rest at 0% waiting, your system at 3.1% total load, but you still have to wait for the answer.
That's why it shows it per thread and not per CPU.
Also, you have 32 threads or 16 cores with multi threading enabled, or 32 cores on that CPU. And chances are you only have one CPU.
But if you have a system with 32 threads, and want to show the user a slider to see select how much processing to give something, it's easier to put them all in one, and show a % for the system, compared to 32 sliders...
1
1
u/DutchOfBurdock 7d ago
You have 32 cores on one die, so when you're using 1 core at full whack, you're only using 0.32% of the die's processing capability, but you are using 100% of that core's ability. It's monitoring per core utilisation rather than the utilisation of the die itself.
1
u/whatever_suits_me 2d ago
Because it makes more sense to see a prices using 400% = equivalent to 4 full CPU capacity than you having to divide 100% with your actual numbers of CPU to know how much (example) 25% means if 100% equals your total amount of available CPU power
0
u/AdventurousSquash 7d ago
I honestly have no idea which of the 3 platforms you’re seeing this on and with what after reading your post. Tools such as top can change mode and show both, just as an example if that’s what you’re using.
37
u/fletch3555 7d ago
Because that's how Linux works and Docker exclusively runs on Linux (haters begone, I know Windows containers are a thing)