So what you are saying is that hard disk is becoming the bottleneck for you if there are multiple builds running at the same time even if you have free slaves picking their nose?
It sounds to me like you can solve your problem by setting number of executors in each slave to 1. At work I have 20 slaves each with 1 executor and the builds REALLY ROAM :) -- Sami 2012/4/5 Jan Seidel <[email protected]>: > Hi there, > > my question is already stated in the title as you can see :) > > I know that you can let jobs "roam" in a node cluster but can you let > it REALLY ROAM? > Jenkins tries to let jobs build on nodes which already have been used > for building that particular job. > That clutters some build queues while other nodes are picking nose. > > The idea was probably to preserve disk space. But I don't need that > intention. "Unimportant jobs" delete their entire workspace upon > finish while the important ones store everything until next run. These > important jobs have a separate harddisk with loads of space. > > I have not only several executors running on each sever but also up to > 3 instances of jenkins slaves for better usage of system ressources > and to box very special jobs. Each slave instance is located on its > own harddisk. > That way do the special jobs and the slaves have exclusive access to > ressources and the jobs may roam in their very own realm. > Sounds a bit weird but works perfect except for this '*%&"%ยง# > preferences to build on the same node that has build the job before. > > The excessive use of the harddisk slows all the builds in a senseless > way as the bus reaches the capacity limit on spikes which happen if > several jobs spawn at the same time and updates their workspace while > there still are loads of unused ressources available on other machines > -.- > > I see at the moment just one solution: split the cluster into more > slaves with less executors and reassign the jobs. > But that is counteracting my idea a bit as this turns from performance > improvement, scalability and convenient usability to further > performance improvement and alleviated administration. > > Has someone an idea how to remove this preference of Jenkins and > simply let the jobs build where most executors are available? > > Cheers > Jan
