Answers: <p>The scheduler itself is not swappable. However, you can set <a href="https://docs.docker.com/compose/compose-file/#resources" rel="nofollow noreferrer">memory constraints and reservations on containers in your service</a>:</p>
  
  <pre><code>version: '3'
  services:
    redis:
      image: redis:alpine
      deploy:
        resources:
          limits:
            cpus: '0.50'
            memory: 50M
          reservations:
            cpus: '0.25'
            memory: 20M
  </code></pre>
  
  <p>The constraint will kill the container if it exceeds the limit even if the host has more memory available. The reservation will ensure that amount of memory on the host is available for the container.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-05-15T14:55:38.997Z
Answers: Although your comment is insightful, it doesn't directly answer the issue. Because it won't help/change how docker will distribute work. If you have 4 nodes, there's still the chance docker will choose to place 100% of the containers in the same node, which happens often if we scale them up too fast.
Answers: fabiopedrosa
Answers: CC BY-SA 4.0
Answers: 2018-05-15T15:02:57.040Z
Answers: The direct answer is that the scheduler itself is not swappable. If you need your own custom built scheduler, then kubernetes may be a better solution.
Answers: BMitch
Answers: CC BY-SA 4.0
Answers: 2018-05-15T15:41:22.570Z
Answers: thanks, that was my understanding as well, but hoped to be wrong.
Answers: fabiopedrosa
Answers: CC BY-SA 4.0
Answers: 2018-05-15T12:39:45.530Z
Answers: 2018-05-15T12:39:45.530Z
Answers: BMitch
Body: <p>We have a 6 node docker swarm running and we often see bad scheduling (clean inbalance) happening.</p>
  
  <p>I've researched this subject, and it seems docker swarm as standalone used to allow a way to choose different strategies to its scheduler, but since swarm was integrated into docker it only supports the spread strategy. In our case, since we are very memory intensive, we would benefit from only considering memory and not CPU/#containers as a metric.</p>
  
  <p>How could we achieve this?</p>
  
Tags: <docker>
Title: Docker swarm custom scheduler
UserDisplayName: fabiopedrosa
ThreadText: # Docker swarm custom scheduler
  
  (Asked by: username_0 on 2018-05-15)
  
  We have a 6 node docker swarm running and we often see bad scheduling (clean inbalance) happening.
  
  I've researched this subject, and it seems docker swarm as standalone used to allow a way to choose different strategies to its scheduler, but since swarm was integrated into docker it only supports the spread strategy. In our case, since we are very memory intensive, we would benefit from only considering memory and not CPU/#containers as a metric.
  
  How could we achieve this?
  
  **Tags:** docker
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-05-15. Score: 1
  
  The scheduler itself is not swappable. However, you can set [memory constraints and reservations on containers in your service](https://docs.docker.com/compose/compose-file/#resources):
  
  ```
  version: '3'
  services:
    redis:
      image: redis:alpine
      deploy:
        resources:
          limits:
            cpus: '0.50'
            memory: 50M
          reservations:
            cpus: '0.25'
            memory: 20M
  
  ```
  
  The constraint will kill the container if it exceeds the limit even if the host has more memory available. The reservation will ensure that amount of memory on the host is available for the container.
  
  > **Comments:**
  > **username_0**: Although your comment is insightful, it doesn't directly answer the issue. Because it won't help/change how docker will distribute work. If you have 4 nodes, there's still the chance docker will choose to place 100% of the containers in the same node, which happens often if we scale them up too fast.  
  > **username_1**: The direct answer is that the scheduler itself is not swappable. If you need your own custom built scheduler, then kubernetes may be a better solution.  
  > **username_0**: thanks, that was my understanding as well, but hoped to be wrong.  
  
  ---
  
  