Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-7444

Distributed builds: Scheduling strategy

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: remoting
    • Labels:
      None
    • Similar Issues:

      Description

      It would be nice if Hudson could schedule build to the most free node, rather then to the node where last build was taken.

      For ex. I have projects A, B, C... configured with "roam=true" and nodes Node1 and Node2 (number of jobs > then number of runners at one node). Last build for A and B was made on Node1, because all executors were busy. Then, if I force build for A and B at the same time, they will build together on Node1, even if Node2 currently do not run any builds. So, build will finish much faster if A would be scheduled to Node1 and B to Node2, or any other free Node.

        Attachments

          Activity

          Hide
          compi Maik Richey added a comment -


          That's the way I would prefer as well. Each suitable node should get one job before they got a second one. That would decrease my build duration dramatically.

          Show
          compi Maik Richey added a comment - That's the way I would prefer as well. Each suitable node should get one job before they got a second one. That would decrease my build duration dramatically.
          Hide
          garen Garen Parham added a comment -

          TeamCity does this, they refer to it as using an "idle" node. All assuming the "idle" node in question has the prerequisites / capabilities to perform the job.

          Show
          garen Garen Parham added a comment - TeamCity does this, they refer to it as using an "idle" node. All assuming the "idle" node in question has the prerequisites / capabilities to perform the job.
          Hide
          edrandall Ed Randall added a comment -

          +1 for this.
          We have 4 slaves, all identical, all the same network distance from the master.
          Each slave is configured to have 2 executors.
          We've noticed that Jenkins always seems to favour one slave in particular, to the extent that it will run 2 jobs on it simultaneously even when all the other slaves are idle.
          This is not ideal so I reduced the executors on that node to 1. Now it does the same behaviour, but preferring a different node.
          I'd prefer if it took account of the current job situation (or recent average CPU load?) when allocating a new job as well.

          Show
          edrandall Ed Randall added a comment - +1 for this. We have 4 slaves, all identical, all the same network distance from the master. Each slave is configured to have 2 executors. We've noticed that Jenkins always seems to favour one slave in particular, to the extent that it will run 2 jobs on it simultaneously even when all the other slaves are idle. This is not ideal so I reduced the executors on that node to 1. Now it does the same behaviour, but preferring a different node. I'd prefer if it took account of the current job situation (or recent average CPU load?) when allocating a new job as well.
          Hide
          bduffy Brent Duffy added a comment -

          Having an option under Manage Jenkins -> Configure System to select from a list of different scheduling strategies would be really nice and much more flexible. For example, one of these three could be selected for the scheduling strategy:

          1. Affinity for last node (default behavior)
          2. Least loaded node
          3. Round-robin node selection

          Of course, this would be with respect to each job's node label (defined in the "Restrict where this project can be run" job config option).

          Show
          bduffy Brent Duffy added a comment - Having an option under Manage Jenkins -> Configure System to select from a list of different scheduling strategies would be really nice and much more flexible. For example, one of these three could be selected for the scheduling strategy: 1. Affinity for last node (default behavior) 2. Least loaded node 3. Round-robin node selection Of course, this would be with respect to each job's node label (defined in the "Restrict where this project can be run" job config option).
          Hide
          yamesi yames isong added a comment -

          I would love to see a slight variation on the original description. As part of the job config that allows the user to select a "roam=true", the user should be allowed to specify with an option to specify a maximum tolerable wait time that would trigger jenkins to seek an idle node

          Show
          yamesi yames isong added a comment - I would love to see a slight variation on the original description. As part of the job config that allows the user to select a "roam=true", the user should be allowed to specify with an option to specify a maximum tolerable wait time that would trigger jenkins to seek an idle node

            People

            • Assignee:
              Unassigned
              Reporter:
              dbubovych dbubovych
            • Votes:
              12 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated: