1 |
lee <lee@××××××××.de> wrote: |
2 |
|
3 |
> <wabenbau@×××××.com> writes: |
4 |
> |
5 |
> > lee <lee@××××××××.de> wrote: |
6 |
> > |
7 |
> >> Hi, |
8 |
> >> |
9 |
> >> what's taking so long when emerging packages despite distcc is |
10 |
> >> used? |
11 |
> >> |
12 |
> >> I have disallowed compiling on the local machine (which is the one |
13 |
> >> emerge is running on) through distcc settings because the local |
14 |
> >> machine is relatively slow. Yet I can see some gcc processes |
15 |
> >> running on the local machine, and emerging goes painfully slow. |
16 |
> >> Using distcc doesn't seem to make it any faster, though disabling |
17 |
> >> local compiling seems to help a bit. |
18 |
> >> |
19 |
> >> Some compilations are being run on the remote machine, so distcc |
20 |
> >> does work. The log file on the remote machine shows compilation |
21 |
> >> times of a few milliseconds up to about 1.5 seconds at most. The |
22 |
> >> distcc server would be finished with the emerging within maybe 15 |
23 |
> >> minutes, and the client takes several hours already. |
24 |
> >> |
25 |
> >> Is there something going wrong? Is there a way to speed things up |
26 |
> >> as much as I would expect from using distcc? |
27 |
> > |
28 |
> > You can try pump mode. Preprocessing is then done on the remote |
29 |
> > server. Depending on your hardware, this could be faster. |
30 |
> > |
31 |
> > But read carefully the manpages of pump and distcc before you use |
32 |
> > it. There are some restrictions you should be aware of. |
33 |
> |
34 |
> I followed the instructions on the wiki which suggest to have |
35 |
> 'FEATURES="distcc distcc-pump"' in make.conf and give instructions how |
36 |
> to set the CPUs. |
37 |
|
38 |
I didn't read the wiki. It's some years ago that I used distcc and IIRC |
39 |
there was no wiki available for it. |
40 |
|
41 |
> > You can also try to optimize the number of concurrent compile |
42 |
> > processes (-j). Watching the load counts of your client and |
43 |
> > server(s) will help you to find out the best value. |
44 |
> |
45 |
> Using -j doesn't really help. The server is pretty much idling --- or |
46 |
> you could say waiting for stuff to compile --- while the client |
47 |
> progresses awfully slowly and isn't overloaded with compilation |
48 |
> processes. If the server would get more load, emerging could be much |
49 |
> much faster. |
50 |
> |
51 |
> Can it be that the client is simply too slow compared to the server to |
52 |
> give it any significant load? (The client isn't exactly slow; it's |
53 |
> slow compared to the server.) |
54 |
|
55 |
I used a pentium 4 laptop as client and two phenom2 quadcore pc as |
56 |
server. I don't remember the settings that I used but I think it |
57 |
was something about -j10 or so. |
58 |
|
59 |
When I compiled large programs, the load count of the servers was |
60 |
high most of the time and they were very busy with compiling. Only |
61 |
at linking time they were waiting for new data. |
62 |
Compilation time was much lower than without distcc. |
63 |
|
64 |
However when I compiled small programs, the benefit of distcc was |
65 |
very small or even null. Also compilation time of OpenOffice was |
66 |
very long, because of the -j1 setting in the ebuild. |
67 |
|
68 |
I don't know the reason of your problem. Maybe you should try it |
69 |
without pump mode to see if this makes a difference. |
70 |
|
71 |
Have you used distccmon to see what happens while compiling? IIRC |
72 |
it shows you exactly what's going on at each host (preprocessing, |
73 |
compiling, waiting). Maybe this will bring some light into the |
74 |
whole thing. |
75 |
|
76 |
And as Dale already said, network speed is very important. |
77 |
|
78 |
-- |
79 |
Regards |
80 |
wabe |