
On 12:05 am, glyph@twistedmatrix.com wrote:
On Aug 19, 2012, at 3:49 PM, exarkun@twistedmatrix.com wrote:
On 03:48 am, glyph@twistedmatrix.com wrote:
For the next sprint, our BuildBot maintainer has assured me that he'll be moving the build master infrastructure to a faster machine before then, so that hopefully it will cope better with the increased load of a sprint.
Slave capacity really needs to be increased as well to handle sprint load.
The major problem with buildbot overload at sprints is the fact that the website becomes so unresponsive that unrelated activity can't take place, e.g. in the bugtracker, for long periods of time.
Correct me if I'm wrong, but if the buildmaster and website are separated, won't that address that problem?
This is entirely possible, I'm not sure. It may also be the case that trac by itself generates sufficient load at sprints to become unusable. We'll find out soon, I guess.
Also, won't the buildmaster evenly work through the backlog of submitted builds, finishing one every few minutes? Or does some parallel stuff happen that makes subsequent builds progressively worse?
Generally not. Instead, the buildmaster will corrupt its local state, wedge itself into non-responsiveness, or enter an infinite loop. Additionally, it will direct one or more slaves to disconnect, crash, or at least corrupt (slave local) kernel state such that a sysadmin needs to restart the machine. Jean-Paul