[
https://issues.jenkins-ci.org/browse/JENKINS-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160405#comment-160405
]
Ed Randall commented on JENKINS-7444:
-------------------------------------
+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.
> Distributed builds: Scheduling strategy
> ---------------------------------------
>
> Key: JENKINS-7444
> URL: https://issues.jenkins-ci.org/browse/JENKINS-7444
> Project: Jenkins
> Issue Type: Improvement
> Components: master-slave
> Affects Versions: current
> Reporter: dbubovych
> Priority: Minor
> Fix For: current
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
