Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
bwhicks at aep.com wrote: > cvsnt-bounces at cvsnt.org wrote on 08/29/2006 10:53:42 AM: > >> For starters, upgrade to a more recent release... get 2.5.04.2428. > > I'd love to, and we will upgrade in the next few months, but I'm stuck for > a while. Hopefully, this will benefit the load issue. Probably not. >> Try tweaking your nice setting for your CruiseControl proceess(es); IIRC >> CruiseControl really hogs your processor and puts a lot of load on the > cvs >> server when it grabs/updates files. > > The Cruise Control server is a separate server than the cvsnt server. It > may be that the Cruise Control script is badly written and performs more > cvs operations than truly necessary, but using top on the linux box shows > that there is never more than two cvs processes running under the cruise > control user at the same time, and it is usually limited to just one > process. Its not the number of processes that's important but how much CPU and IO/wait they cause on the server end... in particular IO/wait is the real killer (if it is above 1% for any amount of time that's an indicator that your IO is being thrashed - time to get SCSI drives, add more RAM for cache, etc.) If you throttle back CC (via nice) it *may* reduce the load its putting on the cvsnt server. Another solution is to rsync your repository onto another server and use that mirror only for CC (so it can then load it as much as it wants without affecting your main repository). > How many concurrent users does cvsnt support? Surely it's more than a half > dozen or so. cvs isn't really a concurrent system, per se... the connection between the client and server is not persistent... everytime a client issues a command it connects to the server and xinetd (or inetd) starts a new process to handle that connection which is then torndown once the command has completed... and most commands complete fairly quickly (i.e. within seconds). I don't think anybody has done any stress testing to see what the maximum (or even comfortable) limits are on this... in real life, you'd be hard pressed to have more than 3 or 4 simultaneous connections (digging through xinetd logs may be interesting...). -- David Somers typographer/programmer/whatever