[distcc] distcc scalability with # of users?

Dan Kegel dank at kegel.com
Fri Apr 16 05:36:02 GMT 2004


Martin Pool wrote:
> On 15 Apr 2004, Dan Kegel <dank at kegel.com> wrote:
> 
>>Martin Pool wrote:
>>
>>>>1. Since the list of hosts read from $prefix/etc/distcc/hosts is
>>>>the same for all workstations, every workstation will
>>>>issue large compile jobs to itself sometimes even though it'd be better
>>>>off only handling preprocessing and linking (right?)
>>>
>>>Linking counts against jobs running on the local machine too.  If it's
>>>linking in parallel with compiling then it should try to do the
>>>compiles remotely.
>>
>>Ah, so it notices that "localhost" is the same machine as "zytor"
>>when running on zytor?
> 
> No, it won't do that.

Then perhaps I should submit a patch to add that, so it won't
try sending jobs to itself by accident?

> I'm not sure then.  Maybe you should have different hosts files for
> each machine to randomize theorder.

Or perhaps add an option to the client for it to randomize the list
of hosts when it first reads it in.  (Maybe a flag in the hosts list?)

>>>If the workstations have a reasonable amount of memory then running a
>>>couple of low-priority daemons should not hurt too much.  Remember it
>>>will only accept about 2*NCPUS.
>>
>>Yes, but that means the compile jobs (which could run faster on
>>some other compile server which is ready and waiting) will execute
>>slower.
> 
> Yes.

Right, I should be able to measure that in an appropriate stress benchmark, then.

>>>We could check the load average before accepting jobs but that is
>>>actually a pretty poor measure for modern machines.
>>
>>Oh, I dunno, the number of processes in 'R' state seems
>>like it'd be a pretty good measure of load if there's
>>plenty of RAM and the distcc job wouldn't cause any disk I/O.
>>Or the number of processes in 'R' or 'D' state if jobs do tend
>>to do disk I/O, maybe.
> 
> One problem is that load average responds pretty slowly to changing
> state.  It might still be worth trying though.

I can get the instantaneous runqueue length, but that's not
the greatest, either.  I'll have to poke around to see what's
available.  (I *would* like this to work well on both MacOSX and Linux,
but I'm not much of a MacOSX hacker, and getting it right for even
one OS would be a big win.)
- Dan

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change



More information about the distcc mailing list