mirror of
https://github.com/containers/podman.git
synced 2025-12-12 09:50:25 +08:00
c9c2f644da
In each options/foo.md, keep a list of where the option is used. This will be valuable to anyone making future edits, and to those reviewing those edits. This may be a controversial commit, because those crossref lists are autogenerated as a side effect of the script that reads them. It definitely violates POLA. And one day, some kind person will reconcile (e.g.) --label, using it in more man pages, and maybe forget to git-commit the rewritten file, and CI will fail. I think this is a tough tradeoff, but worth doing. Without this, it's much too easy for someone to change an option file in a way that renders it inapplicable/misleading for some podman commands. Signed-off-by: Ed Santiago <santiago@redhat.com>
46 lines
2.2 KiB
Markdown
46 lines
2.2 KiB
Markdown
####> This option file is used in:
|
|
####> podman build, container clone, create, pod clone, pod create, run, update
|
|
####> If you edit this file, make sure your changes
|
|
####> are applicable to all of those.
|
|
#### **--cpu-shares**, **-c**=*shares*
|
|
|
|
CPU shares (relative weight).
|
|
|
|
By default, all containers get the same proportion of CPU cycles. This
|
|
proportion can be modified by changing the container's CPU share weighting
|
|
relative to the combined weight of all the running containers.
|
|
Default weight is **1024**.
|
|
|
|
The proportion will only apply when CPU-intensive processes are running.
|
|
When tasks in one container are idle, other containers can use the
|
|
left-over CPU time. The actual amount of CPU time will vary depending on
|
|
the number of containers running on the system.
|
|
|
|
For example, consider three containers, one has a cpu-share of 1024 and
|
|
two others have a cpu-share setting of 512. When processes in all three
|
|
containers attempt to use 100% of CPU, the first container would receive
|
|
50% of the total CPU time. If a fourth container is added with a cpu-share
|
|
of 1024, the first container only gets 33% of the CPU. The remaining containers
|
|
receive 16.5%, 16.5% and 33% of the CPU.
|
|
|
|
On a multi-core system, the shares of CPU time are distributed over all CPU
|
|
cores. Even if a container is limited to less than 100% of CPU time, it can
|
|
use 100% of each individual CPU core.
|
|
|
|
For example, consider a system with more than three cores.
|
|
If the container _C0_ is started with **--cpu-shares=512** running one process,
|
|
and another container _C1_ with **--cpu-shares=1024** running two processes,
|
|
this can result in the following division of CPU shares:
|
|
|
|
| PID | container | CPU | CPU share |
|
|
| ---- | ----------- | ------- | ------------ |
|
|
| 100 | C0 | 0 | 100% of CPU0 |
|
|
| 101 | C1 | 1 | 100% of CPU1 |
|
|
| 102 | C1 | 2 | 100% of CPU2 |
|
|
|
|
On some systems, changing the resource limits may not be allowed for non-root
|
|
users. For more details, see
|
|
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error
|
|
|
|
This option is not supported on cgroups V1 rootless systems.
|