[Buildbot-devel] Best way to utilize multiple slaves?

John Ford jhford at mozilla.com
Fri Sep 3 19:52:29 UTC 2010


Why not try using 
max_builds=1
for your BuildSlaves instead of using locks?  That will make sure that each slave only runs one job.

An example is:

http://hg.mozilla.org/build/buildbot-configs/file/e37e1cb54ae0/mozilla/universal_master_sqlite.cfg#l24


On Sep 3, 2010, at 12:01 PM, Ian Zimmerman wrote:

> I have multiple builders and multiple slaves, and I want to maximize
> the number of builds I get through.  Each builder tortures its host
> pretty badly so only one can run at a time on each slave.  I use a
> slave lock on the builder to enforce that.  Right now there's a
> separate Scheduler for each, but I guess there's no reason why I
> couldn't use a single AnyBranchScheduler.
> 
> I configured each builder (say B1 and B2) to use multiple slaves (say
> S1 and S2), and I was naively expecting that when B1 is running on S1
> (taking the S1 instance of the slave lock), and a change for B2 comes
> in, B2 will be scheduled immediately to run on S2.  But that doesn't
> seem to happen; instead B2 is scheduled to run on S1 as well and waits
> for the lock to drop.  The only situation when I get some
> parallelism is when 2 changes for B1 come in at the same time,
> then one of the builds run on S1 and the other on S2.
> 
> So, how can I make this better?  Would using AnyBranchScheduler work?
> Or do I need to refactor to use a single builder for everything?
> 
> Ian
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20100903/fbd8a878/attachment.html>


More information about the devel mailing list