free counter
Science And Nature

How exactly to Set a Memory Limit for Docker Containers

Graphic showing the Docker logo

Docker containers default to running without any resource constraints. Processes running in containers are absolve to utilize limitless levels of memory, potentially impacting neighboring containers along with other workloads on your own host.

That is hazardous in production environments. Each container ought to be configured having an appropriate memory limit to avoid runaway resource consumption. This can help reduce contention that will maximize overall system stability.

How Docker Memory Limits Work

Docker enables you to set hard and soft memory limits on individual containers. These have different effects on the quantity of available memory and the behavior once the limit is reached.

  • Hard memory limits set a complete cap on the memory provided to the container. Exceeding this limit will normally cause the kernel out-of-memory killer to terminate the container process.
  • Soft memory limits indicate the quantity of memory a containers likely to use. The container is permitted to utilize more memory when capacity can be acquired. It may be terminated if its exceeding a soft limit throughout a low-memory condition.

Docker also provides controls for setting swap memory constraints and changing what goes on whenever a memory limit is reached. Youll observe how to utilize these in the next sections.

Setting Hard and Soft Memory Limits

A difficult memory limit is defined by the docker run commands -m or --memory flag. It requires a value such as for example 512m (for megabytes) or 2g (for gigabytes):

$ docker run --memory=512m my-app:latest

Containers have the very least memory dependence on 6MB. Attempting to use --memory values significantly less than 6m may cause one.

Soft memory limits are set with the --memory-reservation flag. This value must be less than --memory. The limit is only going to be enforced when container resource contention occurs or the host is low on physical memory.

$ docker run --memory=512m --memory-reservation=256m my-app:latest

This example starts a container which includes 256MB of reserved memory. The procedure could possibly be terminated if its using 300MB and capacity is running out. It’ll always stop if usage exceeds 512MB.

Managing Swap Memory

Containers could be allocated swap memory to support high usage without impacting physical memory consumption. Swap allows the contents of memory to be written to disk after the available RAM has been depleted.

The --memory-swap flag controls the quantity of swap space available. It only works together with --memory. Once you set --memory and --memory-swap to different values, the swap value controls the quantity of memory open to the container, including swap space. The worthiness of --memory determines the part of the total amount thats physical memory.

$ docker run --memory=512m --memory-swap=762m my-app:latest

This container has usage of 762MB of memory which 512MB is physical RAM. The rest of the 250MB is swap space stored on disk.

Setting --memory without --memory-swap provides container usage of the same level of swap space as physical memory:

$ docker run --memory=512m my-app:latest

This container includes a total of 1024MB of memory, comprising 512MB of RAM and 512MB of swap.

Swap could be disabled for a container by setting the --memory-swap flag to exactly the same value as --memory. As --memory-swap sets the quantity of memory, and --memory allocates the physical memory proportion, youre instructing Docker that 100% of the available memory ought to be RAM.

In every cases swap only works when its enabled on your own host. Swap reporting inside containers is unreliable and shouldnt be utilized. Commands such as for example free which are executed inside a container will display the quantity of swap space on your own Docker host, not the swap accessible to the container.

Disabling Out-of-Memory Process Kills

Out-of-memory errors in a container normally cause the kernel to kill the procedure. This results in the container stopping with exit code 137.

Like the optional flag --oom-kill-disable together with your docker run command disables this behavior. Rather than stopping the procedure, the kernel only will block new memory allocations. The procedure will appear to hold and soon you either reduce its memory use, cancel new memory allocations, or manually restart the container.

This flag shouldnt be utilized unless youve implemented mechanisms for resolving out-of-memory conditions yourself. Its usually easier to allow kernel kill the procedure, causing a container restart that restores normal memory consumption.


Docker containers come without pre-applied resource constraints. This leaves container processes absolve to consume unlimited memory, threatening the stability of one’s host.

In this post youve learned how exactly to set hard and soft container memory limits to lessen the opportunity youll hit an out-of-memory situation. Setting these limits across all of your containers will certainly reduce resource contention and assist you to stay inside your hosts physical memory capacity. You should look at using CPU limits alongside your memory caps these will prevent individual containers with a higher CPU demand from detrimentally impacting their neighbors.

Read More

Related Articles

Leave a Reply

Your email address will not be published.

Back to top button

Adblock Detected

Please consider supporting us by disabling your ad blocker