---
title: Resource constraints
weight: 30
description: Specify the runtime options for a container
keywords: docker, daemon, configuration, runtime
aliases:
- /engine/admin/resource_constraints/
- /config/containers/resource_constraints/
---
By default, a container has no resource constraints and can use as much of a
given resource as the host's kernel scheduler allows. Docker provides ways
to control how much memory, or CPU a container can use, setting runtime
configuration flags of the `docker run` command. This section provides details
on when you should set such limits and the possible implications of setting them.
Many of these features require your kernel to support Linux capabilities. To
check for support, you can use the
[`docker info`](/reference/cli/docker/system/info.md) command. If a capability
is disabled in your kernel, you may see a warning at the end of the output like
the following:
```console
WARNING: No swap limit support
```
Consult your operating system's documentation for enabling them. See also the
[Docker Engine troubleshooting guide](../daemon/troubleshoot.md#kernel-cgroup-swap-limit-capabilities)
for more information.
## Memory
## Understand the risks of running out of memory
It's important not to allow a running container to consume too much of the
host machine's memory. On Linux hosts, if the kernel detects that there isn't
enough memory to perform important system functions, it throws an `OOME`, or
`Out Of Memory Exception`, and starts killing processes to free up
memory. Any process is subject to killing, including Docker and other important
applications. This can effectively bring the entire system down if the wrong
process is killed.
Docker attempts to mitigate these risks by adjusting the OOM priority on the
Docker daemon so that it's less likely to be killed than other processes
on the system. The OOM priority on containers isn't adjusted. This makes it more
likely for an individual container to be killed than for the Docker daemon
or other system processes to be killed. You shouldn't try to circumvent
these safeguards by manually setting `--oom-score-adj` to an extreme negative
number on the daemon or a container, or by setting `--oom-kill-disable` on a
container.
For more information about the Linux kernel's OOM management, see
[Out of Memory Management](https://www.kernel.org/doc/gorman/html/understand/understand016.html).
You can mitigate the risk of system instability due to OOME by:
- Perform tests to understand the memory requirements of your application
before placing it into production.
- Ensure that your application runs only on hosts with adequate resources.
- Limit the amount of memory your container can use, as described below.
- Be mindful when configuring swap on your Docker hosts. Swap is slower than
memory but can provide a buffer against running out of system memory.
- Consider converting your container to a
[service](/manuals/engine/swarm/services.md), and using service-level constraints
and node labels to ensure that the application runs only on hosts with enough
memory
### Limit a container's access to memory
Docker can enforce hard or soft memory limits.
- 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.
Some of these options have different effects when used alone or when more than
one option is set.
Most of these options take a positive integer, followed by a suffix of `b`, `k`,
`m`, `g`, to indicate bytes, kilobytes, megabytes, or gigabytes.
| Option | Description |