By default, a container has no resource constraints and may use as a lot of a given useful resource because the host's kernel scheduler allows. Docker supplies ways to control how a lot memory, or CPU a container can use, setting runtime configuration flags of the docker run command. This section provides details on when you need to set such limits and the doable implications of setting them. Many of these options require your kernel to help Linux capabilities. To test for support, you need to use the docker info command. Seek the advice of your working system's documentation for enabling them. See additionally the Docker Engine troubleshooting guide for extra data. It is important not to allow a running container to consume a lot of the host machine's memory. On Linux hosts, if the kernel detects that there is not enough memory to perform important system functions, it throws an OOME, or Out Of Memory Exception, and begins killing processes to free up memory. Any process is topic to killing, including Docker and different important functions.
reference.com

This could successfully deliver your complete system down if the flawed course of is killed. Docker attempts to mitigate these risks by adjusting the OOM priority on the Docker daemon so that it's much less more likely to be killed than different processes on the system. The OOM precedence on containers is not adjusted. This makes it more probably for a person container to be killed than for the Docker daemon or different system processes to be killed. You shouldn't attempt to avoid these safeguards by manually setting --oom-score-adj to an extreme detrimental number on the daemon or a container, or by setting --oom-kill-disable on a container. For extra information concerning the Linux kernel's OOM management, see Out of Memory Administration. Perform tests to grasp the memory necessities of your application before placing it into manufacturing. Make sure that your utility runs only on hosts with adequate sources. Restrict the quantity of memory your container can use, as described beneath. Be mindful when configuring swap on your Docker hosts.

Swap is slower than memory but can present a buffer in opposition to working out of system memory. Docker can implement arduous or tender memory limits. Laborious limits let the container use not more than a hard and fast amount of memory. Delicate limits let the container use as much memory as it needs until sure situations are met, comparable to when the kernel detects low memory or contention on the host machine. Some of these options have different effects when used alone or when more than one possibility is ready. Most of these choices take a optimistic integer, followed by a suffix of b, ok, m, g, to indicate bytes, kilobytes, megabytes, or gigabytes. For extra details about cgroups and memory in general, see the documentation for Memory Resource Controller. Using swap permits the container to put in writing excess memory requirements to disk when the container has exhausted all the RAM that is available to it.

There is a efficiency penalty for functions that swap memory to disk often. If --memory-swap is about to a constructive integer, then both --memory and --memory-swap should be set. 300m of memory and 700m (1g - 300m) swap. If --memory-swap is about to 0, the setting is ignored, and the value is handled as unset. If --memory-swap is ready to the same value as --memory, and --Memory Wave System is about to a constructive integer, the container doesn't have access to swap. See Stop a container from using swap. If --memory-swap is unset, and --memory is ready, the container can use as much swap because the --memory setting, if the host container has swap memory configured. 600m in total of memory and swap. If --memory-swap is explicitly set to -1, the container is allowed to make use of unlimited swap, up to the amount obtainable on the host system. Inside the container, tools like free report the host's accessible swap, not what's obtainable contained in the container.