mirror of https://github.com/docker/cli.git
docs: fix cpu.shares part in man pages
The original description has some mistakes and lack of many useful information, I rewrite them to make it accurate and complete. Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
This commit is contained in:
parent
80728bcd7b
commit
ef5874f0a9
|
@ -423,24 +423,35 @@ We have four ways to set memory usage:
|
||||||
It is not allowed to use more than L bytes of memory, swap *plus* memory
|
It is not allowed to use more than L bytes of memory, swap *plus* memory
|
||||||
usage is limited by S.
|
usage is limited by S.
|
||||||
|
|
||||||
The operator can increase the priority of this container with
|
The operator can modify the priority of this container with
|
||||||
the `-c` option. By default, all containers run at the same priority and
|
the `-c` option. By default, all containers run at the same priority
|
||||||
get the same proportion of CPU cycles, but you can tell the kernel to
|
and get the same proportion of CPU cycles, the value specified must be 2
|
||||||
give more shares of CPU time to one or more containers when you start
|
or higher, if you are not setting `-c` or `--cpu-shares`, the default
|
||||||
them via Docker.
|
shares of CPU time would be 1024.
|
||||||
|
|
||||||
The flag `-c` or `--cpu-shares` with value 0 indicates that the running
|
CPU shares is kind of CPU bandwidth weight, the proportion will only
|
||||||
container has access to all 1024 (default) CPU shares. However, this value
|
reflect when CPU-intensive processes are running. When tasks in one
|
||||||
can be modified to run a container with a different priority or different
|
container are idle, other containers are allowed to borrow the left-over
|
||||||
proportion of CPU cycles.
|
CPU time.
|
||||||
|
|
||||||
E.g., If we start three {C0, C1, C2} containers with default values
|
The actual amount of CPU time can very depending on the number of containers
|
||||||
(`-c` OR `--cpu-shares` = 0) and one {C3} with (`-c` or `--cpu-shares`=512)
|
running on the system. If a container have a share of 1024 and two other
|
||||||
then C0, C1, and C2 would have access to 100% CPU shares (1024) and C3 would
|
containers have share of 512, when processes in all containers attempt to
|
||||||
only have access to 50% CPU shares (512). In the context of a time-sliced OS
|
use 100% of CPU, the first container would receive 50% of all CPU time, if
|
||||||
with time quantum set as 100 milliseconds, containers C0, C1, and C2 will run
|
another container with share of 1024 is added, the first container would
|
||||||
for full-time quantum, and container C3 will run for half-time quantum i.e 50
|
only get 33% of the CPU (the rest receive 16.5%, 16.5% and 33% of CPU).
|
||||||
milliseconds.
|
|
||||||
|
Note that shares of CPU time are distributed per all CPU cores on multi-core
|
||||||
|
systems. Even if a container is limited to less than 100% of CPU time, it
|
||||||
|
may use 100% of each individual CPU core. E.g., if we start {C0} container
|
||||||
|
with (`-c` = 512) and {C1} with (`-c` = 1024), we start three CPU-intensive
|
||||||
|
processes (one in {C0} and two in {C1}) on a system with more than three
|
||||||
|
cores, might results 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
|
||||||
|
|
||||||
## Runtime privilege, Linux capabilities, and LXC configuration
|
## Runtime privilege, Linux capabilities, and LXC configuration
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue