[webkit-dev] git.webkit.org problem

Osztrogonac Csaba oszi at inf.u-szeged.hu
Thu Mar 1 07:56:35 PST 2012


Hi,

Marc-Antoine Ruel írta:
> Here are some things that may help;
> 
> *#1 svn server overloading when all the slaves bootstrap at the same time*
> The only good work around is to keep an internal read-only svn-mirror 
> that the slaves use instead of the real svn server.
> 
> This means that builds must be triggered on the svn-mirror, which may 
> incurs a delay of a few seconds, due to svnsync polling. My hypothesis 
> is that svn has repo-wide locks while committing, so when there are a 
> lot of readers, they are all starved whenever some action is happening. 
> Doing the svn-mirror trick helped us to scale in the range past /several 
> hundreds of simultaneous active connections/. As a guidance, gclient 
> sync does 8 svn connections per slave by default. Scale that to hundreds 
> of slaves waking up at the same time...
> 
> Also, serving the read-only svn server from a set of apache frontends 
> helps. We do that with src.chromium.org <http://src.chromium.org>. To be 
> clear, above I was talking about a DMZ-only mirror. It is a different 
> one from the apache frontends. Implementing both has the biggest benefit.

We like the idea to setup svn mirrors, and we are ready to setup an svn mirror
for Qt buildslaves hosted in Szeged. (6 slaves connected to build.webkit.org master
and 13 slaves connected to build.webkit.sed.hu master) I think this mirror would
help to reduce the load of svn.webkit.org and avoid "rm -rf" because of slow and
not so stable trans-atlantic network connection.

If there isn't any objection against adding an svn.webkit.sed.hu mirror,
we will start to setup the server and prepare the master.cfg change to
make slaves to be able to use svn mirrors, and add new scheduler to trigger
slaves depends on their svn mirror used.

And one more technical question. Could you add an svn post-commit hook to
do svnsync on the mirror svn server if we finished setting up the server?

br,
Ossy


More information about the webkit-dev mailing list