From 314c2e76a2734f84317a1ba830043c76948a75fa Mon Sep 17 00:00:00 2001 From: Andrey Sobolev Date: Tue, 6 May 2025 15:58:30 +0300 Subject: [PATCH 1/2] Fix typos in Resource constraints manual --- .../engine/containers/resource_constraints.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/manuals/engine/containers/resource_constraints.md b/content/manuals/engine/containers/resource_constraints.md index 09e04a4a37e4..14feee612c35 100644 --- a/content/manuals/engine/containers/resource_constraints.md +++ b/content/manuals/engine/containers/resource_constraints.md @@ -69,8 +69,8 @@ You can mitigate the risk of system instability due to OOME by: Docker can enforce hard or soft memory limits. -- Hard limits lets the container use no more than a fixed amount of memory. -- Soft limits lets the container use as much memory as it needs unless certain +- Hard limits let the container use no more than a fixed amount of memory. +- Soft limits let the container use as much memory as it needs unless certain conditions are met, such as when the kernel detects low memory or contention on the host machine. @@ -117,7 +117,7 @@ Its setting can have complicated effects: - If `--memory-swap` is unset, and `--memory` is set, the container can use as much swap as the `--memory` setting, if the host container has swap - memory configured. For instance, if `--memory="300m"` and `--memory-swap` is + memory configured. For instance, if `--memory="300m"` and `--memory-swap` are not set, the container can use 600m in total of memory and swap. - If `--memory-swap` is explicitly set to `-1`, the container is allowed to use @@ -162,7 +162,7 @@ a container. Consider the following scenarios: an OOM error. If the kernel memory limit is higher than the user memory limit, the kernel limit doesn't cause the container to experience an OOM. -When you enable kernel memory limits, the host machine tracks "high water mark" +When you enable kernel memory limits, the host machine tracks the "high water mark" statistics on a per-process basis, so you can track which processes (in this case, containers) are using excess memory. This can be seen per process by viewing `/proc//status` on the host machine. @@ -186,7 +186,7 @@ the container's cgroup on the host machine. | :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--cpus=` | Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set `--cpus="1.5"`, the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting `--cpu-period="100000"` and `--cpu-quota="150000"`. | | `--cpu-period=` | Specify the CPU CFS scheduler period, which is used alongside `--cpu-quota`. Defaults to 100000 microseconds (100 milliseconds). Most users don't change this from the default. For most use-cases, `--cpus` is a more convenient alternative. | -| `--cpu-quota=` | Impose a CPU CFS quota on the container. The number of microseconds per `--cpu-period` that the container is limited to before throttled. As such acting as the effective ceiling. For most use-cases, `--cpus` is a more convenient alternative. | +| `--cpu-quota=` | Impose a CPU CFS quota on the container. The number of microseconds per `--cpu-period` that the container is limited to before being throttled. As such acting as the effective ceiling. For most use-cases, `--cpus` is a more convenient alternative. | | `--cpuset-cpus` | Limit the specific CPUs or cores a container can use. A comma-separated list or hyphen-separated range of CPUs a container can use, if you have more than one CPU. The first CPU is numbered 0. A valid value might be `0-3` (to use the first, second, third, and fourth CPU) or `1,3` (to use the second and fourth CPU). | | `--cpu-shares` | Set this flag to a value greater or less than the default of 1024 to increase or reduce the container's weight, and give it access to a greater or lesser proportion of the host machine's CPU cycles. This is only enforced when CPU cycles are constrained. When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. `--cpu-shares` doesn't prevent containers from being scheduled in Swarm mode. It prioritizes container CPU resources for the available CPU cycles. It doesn't guarantee or reserve any specific CPU access. | @@ -234,7 +234,7 @@ for real-time tasks per runtime period. For instance, with the default period of containers using the real-time scheduler can run for 950000 microseconds for every 1000000-microsecond period, leaving at least 50000 microseconds available for non-real-time tasks. To make this configuration permanent on systems which use -`systemd`, create a systemd unit file for the `docker` service. For an example, +`systemd`, create a systemd unit file for the `docker` service. For example, see the instruction on how to configure the daemon to use a proxy with a [systemd unit file](../daemon/proxy.md#systemd-unit-file). @@ -343,6 +343,6 @@ environment variables. More information on valid variables can be found in the [nvidia-container-toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html) documentation. These variables can be set in a Dockerfile. -You can also use CUDA images which sets these variables automatically. See the +You can also use CUDA images, which set these variables automatically. See the official [CUDA images](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda) NGC catalog page. From 8922ad7e7b675866ca6a8aa3246906b23fc45bf7 Mon Sep 17 00:00:00 2001 From: Andrey Sobolev Date: Tue, 6 May 2025 16:02:35 +0300 Subject: [PATCH 2/2] Undo incorrect change --- content/manuals/engine/containers/resource_constraints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/manuals/engine/containers/resource_constraints.md b/content/manuals/engine/containers/resource_constraints.md index 14feee612c35..5f9efc616eba 100644 --- a/content/manuals/engine/containers/resource_constraints.md +++ b/content/manuals/engine/containers/resource_constraints.md @@ -117,7 +117,7 @@ Its setting can have complicated effects: - If `--memory-swap` is unset, and `--memory` is set, the container can use as much swap as the `--memory` setting, if the host container has swap - memory configured. For instance, if `--memory="300m"` and `--memory-swap` are + memory configured. For instance, if `--memory="300m"` and `--memory-swap` is not set, the container can use 600m in total of memory and swap. - If `--memory-swap` is explicitly set to `-1`, the container is allowed to use