[users at bb.net] Symmetric multi-master on the same machine

[Pierre Tardy]

Hello,

It looks like you are having schedulers running on both masters, which
might create this problem.
Make sure you run scheduler on only one master.
Normally buildbot should take care of having only one scheduler of a kind
in the whole setup, but I think it does not work very well.

Also, indeed it is not recommended to do large file transfers with the
transfer steps. Thos have the tendency of saturating the tcp connection
between master and worker.

It is more recommended to use artifactory/nexus or just simple scp commands.

Regards
Pierre


Le mer. 2 déc. 2020 à 20:46, Vlad Bogolin <vlad at mariadb.org> a écrit :

> Hi,
>
> I was wondering if you have any tips on setting up a
> symmetric multi-master for handling builds for masters running on the same
> machine.
>
> Currently, we have a two master configuration where one master is serving
> the web service exclusively while the second is coordinating the builds.
> Before switching to this two master configuration, the interface was quite
> slow when multiple builds were running, but now this issue is solved.
> However, there still is a delay for starting builds so we would like to add
> a third master for handling the builds that shares the same config with the
> exiting one. We use DockerLatentWorkers exclusively and simply adding a new
> master doubles the amount of running builds instead of splitting the load.
> Do you have any tips on what might be the easiest solution to split the
> load? The masters run on the same machine.
>
> P.S Also, we have quite a few file transfers between workers and master
> and we have sometimes noticed a very slow transfer speed. Can this be
> caused by an overloaded master?
>
> Thanks,
> Vlad Bogolin
> _______________________________________________
> users mailing list
> users at buildbot.net
> https://lists.buildbot.net/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20201202/c064c1a5/attachment.html>