@@ -791,6 +791,74 @@ appends a new placement preference after all existing placement preferences.
791791` --placement-pref-rm ` removes an existing placement preference that matches the
792792argument.
793793
794+ ### Specify memory requirements and constraints for a service (--reserve-memory and --limit-memory)
795+
796+ If your service needs a minimum amount of memory in order to run correctly,
797+ you can use ` --reserve-memory ` to specify that the service should only be
798+ scheduled on a node with this much memory available to reserve. If no node is
799+ available that meets the criteria, the task is not scheduled, but remains in a
800+ pending state.
801+
802+ The following example requires that 4GB of memory be available and reservable
803+ on a given node before scheduling the service to run on that node.
804+
805+ ``` bash
806+ $ docker service create --reserve-memory=4GB --name=too-big nginx:alpine
807+ ```
808+
809+ The managers won't schedule a set of containers on a single node whose combined
810+ reservations exceed the memory available on that node.
811+
812+ After a task is scheduled and running, ` --reserve-memory ` does not enforce a
813+ memory limit. Use ` --limit-memory ` to ensure that a task uses no more than a
814+ given amount of memory on a node. This example limits the amount of memory used
815+ by the task to 4GB. The task will be scheduled even if each of your nodes has
816+ only 2GB of memory, because ` --limit-memory ` is an upper limit.
817+
818+ ``` bash
819+ $ docker service create --limit-memory=4GB --name=too-big nginx:alpine
820+ ```
821+
822+ Using ` --reserve-memory ` and ` --limit-memory ` does not guarantee that Docker
823+ will not use more memory on your host than you want. For instance, you could
824+ create many services, the sum of whose memory usage could exhaust the available
825+ memory.
826+
827+ You can prevent this scenario from exhausting the available memory by taking
828+ into account other (non-containerized) software running on the host as well. If
829+ ` --reserve-memory ` is greater than or equal to ` --limit-memory ` , Docker won't
830+ schedule a service on a host that doesn't have enough memory. ` --limit-memory `
831+ will limit the service's memory to stay within that limit, so if every service
832+ has a memory-reservation and limit set, Docker services will be less likely to
833+ saturate the host. Other non-service containers or applications running directly
834+ on the Docker host could still exhaust memory.
835+
836+ There is a downside to this approach. Reserving memory also means that you may
837+ not make optimum use of the memory available on the node. Consider a service
838+ that under normal circumstances uses 100MB of memory, but depending on load can
839+ "peak" at 500MB. Reserving 500MB for that service (to guarantee can have 500MB
840+ for those "peaks") results in 400MB of memory being wasted most of the time.
841+
842+ In short, you can take a more conservative or more flexible approach:
843+
844+ - ** Conservative** : reserve 500MB, and limit to 500MB. Basically you're now
845+ treating the service containers as VMs, and you may be losing a big advantage
846+ containers, which is greater density of services per host.
847+
848+ - ** Flexible** : limit to 500MB in the assumption that if the service requires
849+ more than 500MB, it is malfunctioning. Reserve something between the 100MB
850+ "normal" requirement and the 500MB "peak" requirement". This assumes that when
851+ this service is at "peak", other services or non-container workloads probably
852+ won't be.
853+
854+ The approach you take depends heavily on the memory-usage patterns of your
855+ workloads. You should test under normal and peak conditions before settling
856+ on an approach.
857+
858+ On Linux, you can also limit a service's overall memory footprint on a given
859+ host at the level of the host operating system, using ` cgroups ` or other
860+ relevant operating system tools.
861+
794862### Specify maximum replicas per node (--replicas-max-per-node)
795863
796864Use the ` --replicas-max-per-node ` flag to set the maximum number of replica tasks that can run on a node.
0 commit comments