<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Olaf, ssh and cvs are usually failing now. It is quite bad now.<br>I have to retry cvs -z3 diff and cvs -z3 commit multiple times to get them to work.<br><br> - Jay<br><br><br>> Date: Mon, 23 Aug 2010 13:41:40 +0200<br>> From: wagner@elegosoft.com<br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com; m3-support@elego.de<br>> Subject: RE: [M3devel] changes in CM3 continuous integration setup<br>> <br>> Quoting Jay K <jay.krell@cornell.edu>:<br>> <br>> > I don't really understand all of this.<br>> > Surely CVS can tolerate more than 10 "active" users?<br>> > Or is it really awful?<br>> > (or, most likely, both)<br>> > What if they all poll much less than once an hour?<br>> <br>> It's not just CVS. The machine is running our WWW services, FTP,<br>> CVSup, backup for several hosts and secondary mail services.<br>> <br>> > Let's say we have 12 machines.<br>> > Have them each poll 4 times per day: 48 polls.<br>> > So that's just one operation every 30 minutes.<br>> > One poll, possibly followed by one update.<br>> <br>> That would be an individual setup for all jobs regarding polling.<br>> It's of course possible, but more tedious work again.<br>> <br>> > Or, didn't you set it up so only one machine polled and all the <br>> > other builds would follow it, serially?<br>> > If not, that makes sense.<br>> > Have one machine poll every 30 minutes.<br>> > If it finds something, it builds, and the next one builds.<br>> > If it finds nothing, then nothing occurs.<br>> > Surely this would work ok?<br>> > It merely serializes all of our Hudson jobs?<br>> > Which is, granted, rather unfortunate.<br>> > Adding machines should allow great parallelism.<br>> > And CVS is read-mostly, so should handle plenty of load. <br>> > "Read-mostly" being<br>> > a property that makes systems easier to scale.<br>> <br>> The current setup is suboptimal.<br>> I've changed things in a way that could be done quickly.<br>> But it's not easy to foretell how any change will affect the load<br>> and responsiveness, as it isn't even clear where the limits are; and<br>> other services are continually competing for resources, too.<br>> <br>> I've set up continuous logging of system load, top and iotop.<br>> You can get a quick summary with this job:<br>> <br>> http://hudson.modula3.com:8080/view/zzz/job/sysload<br>> <br>> We'll monitor this for some days and see how our changes affect<br>> the situation.<br>> <br>> Complete logs are written to Hudson's ~/log/ directory.<br>> <br>> > I assume if I bothered to learn to use cvsup, it would help much?<br>> > We'd have a few mirrors and it'd "fan out well"?<br>> > e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5?<br>> <br>> I think we'd only need one CVS mirror that the continous integration<br>> could use. Unfortunately, our system administrator is on vacance (his wife's<br>> expecting their second baby) right now, and I haven't got any machine<br>> for that readily available.<br>> <br>> We'll sort that out, though; don't worry too much. It may need some<br>> weeks, but we'll find an acceptable solution without much limitations.<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br> </body>
</html>