Main /
Verteiltes Builden mit distcc |
AllgemeinKnowledge Base
Community
|
Gebaut wird immer mit Was folgendes besagt: der gesamte Build-Prozess lief 1:05 Minuten, im Usermode wurden 59 Sek. verbraten, sys soll hier nicht weiter interessieren. Lets start. Die Tabellen sind vielleicht etwas komisch zu lesen, aber ich habe auf dem Rechner immer die 4.1 Test auf
|
host | moon/1 | phobos/1 | sputnik/1 | localhost/1 |
real | 6:10 | 4:57 | 1:06 | 0:57 |
user | 0:08 | 0:08 | 0:08 | 0:52 |
Zu den Zeiten: localhost
heisst, das Programm wurde nur auf lemur
kompiliert, es hat 57sek gedauert. Bei den anderen Rechnern entsprechend. Es wurde also immer nur ein Rechner zum Compilieren verwendet, wobei lemur
der Rechner war von dem das Ganze initiiert wurde.
Interessant ist, dass 'user' (wird nur auf entfernten Rechnern gebaut) immer 8sek. beträgt. Das ist der Overhead, also die Zeit die Präprozessor und Linker brauchen, um die Sourcen zusammenzustellen und die fertigen Objekte zu erstellen.
time make -j2
host | moon/1 phobos/1 | sputnik/1 localhost/1 |
real | 2:51 | 0:34 |
user | 0:08 | 0:31 |
Hier ist zu sehen, dass auch zwei langsame Rechner durchaus nütylich sein können können. Zusammen brauchen phobos und moon ca. 3min zum Builden, fast doppelt so schnell als einer der beiden allein.
Ok, die beiden schnelleren Rechner brauchen zusammen nur 34sek.
sputnik
spare ich mir hier, Ergebnisse sind nicht viel anders.
phobos
host | moon/1 | localhost/1 | sputnik/1 | lemur/1 |
real | 5:20 | 1:33 | 1:28 | |
user | 5:11 | 0:33 | 0:33 |
Hier sieht man, dass der Overhead 33sek beträgt, die ältere Hardware fordert ihren Tribut. (SCSI 4GB IBM DCAS, aber 100MBit Netz)
time make -j2
host | sputnik/2 | lemur/2 |
real | 1:13 | 1:10 |
user | 0:33 | 0:33 |
Hier kann man schön sehen, das die Latenz durch gleichzeitiges Builden etwas gemildert werden kann. Normal wird ja ein Source durch den Präprozessor getrieben, an den anderen Rechner übertragen, dort gebuildet, assembliert und zurück geschickt.
Setzt man jetzt ein /2
ein (der Rechner nimmt 2 Prozesse gleichzeitig entgegen) ist der entfernte Rechner besser ausgelastet, da er nicht auf den langsameren warten muß. Also ist /2
(mindestens) fuer entfernte Rechner eigentlich Pflicht.
time make -j2
host | sputnik/1 lemur/1 |
real | 0:56 |
user | 0:33 |
Ist etwas besser, es sind halt 2 Rechner. Aber trotzdem wird jeder etwas warten müssen, also /2
setzen und entsprechend mehr Prozesse starten.
time make -j4
host | sputnik/2 lemur/2 |
real | 0:50 |
user | 0:33 |
Nicht mehr so viel schneller. Die alte Hardware ist einfach zu langsam. Nichtsdestotrotz ist es nicht schlecht, mit zwei schnellen Rechnern im Netz das Builden um den Faktor 6 zu beschleunigen. Doch Vorsicht, das kann nach hinten losgehen, denn wenn noch ein langsamer Rechner dazukommt kann der Ergebnis schnell zusammenbrechen, da zu lange auf die Krücke gewartet werden muss.
time make -j5
host | localhost/1 sputnik/2 lemur/2 |
real | 1:08 |
user | 1:02 |
Beim nächsten Ergebnis ist nur die Reihenfolge in /etc/distcc/hosts
vertauscht. Das sagt uns, dass die langsamen Rechner immer nach hinten sollten, Damit sie immer zum Schluss mit Aufgaben beliefert werden. Doch auch das kann nach hinten losgehen, also besser extrem langsame Rechner ganz weglassen.
time make -j5
host | sputnik/2 lemur/2 localhost/1 |
real | 0:56 |
user | 0:44 |
Es ist also durchaus Potenzial in distcc.
Doch auch distcc kann nicht zaubern, so ist der Gewinn beim Kompilieren zwar sehr hoch, aber der Overhead z.B. bei emerge
doch um einiges höher, denn da wird zuerst entpackt (was auf langsamen Maschinen sehr lange dauern kann) dann wird mittels configure
die Umgebung geprüft (was auch sehr lange dauert) dann wird kompiliert (was jetzt allerdings viel schneller geht) erst dann wird installiert und aufgeräumt. Besonders bei großen Paketen wie X, KDE oder Firefox wird distcc auch eine menge bringen wenn der "kleine" Rechner die Zielplattform sein soll, und dazu wird man distcc meistens verwenden.
Wenn ich mal Zeit bzw. Lust habe werde ich in phobos
mal eine schnellere Platte einbauen und dann mal gucken ob der Overhead sinkt, was ich mal nicht annehme, da
bei der Größe der Sourcen und dem compiler etc. alles brav in die Buffer passt und somit fast keine Plattenzugriffe mehr nötig waren.
BTW: Selbst auf phobos
mit seinen nur 80MB RAM wurde der Swap nicht gebraucht, um mittels -j5
die Sourcen zu bilden, somit ist die Speicherverwaltung von Linux richtig gut.
Ist einer der eingetragenen Rechner in der /usr/distcc/hosts
nicht erreichbar ist das Ergebnis unterschiedlich, mal geht die Erkennung sehr fix, mal dauert es ewig. Einen richtigen Weg habe ich noch nicht gefunden. Werde aber hier noch ein wenig analysieren
[Update zu Nikolausi]
Nur mal um zu zeigen, das es auch noch schneller geht, wenn mein neues Monster im Hintergrund steht. Habe mal /usr/distcc/hosts
nur auf ihn gelenkt, somit wird nur dort kompiliert. Der Hauptrechner ist dabei sputnik
time make -j2
host | monster/2 |
real | 0:16 |
user | 0:08 |
Mittlerweile ist Lars' Rechnerpark geupdated worden.
Verwendung finden jetzt 5 Rechner
Proz. Typ | Name | MHz | RAM | Kommentar |
Pentium MMX | moon | 200 | 96MB | nur 64MB gecached, VX Board |
Pentium III | sputnik | 500 | 192MB | Laptop |
Athlon64 3k+ | monster | 1800 | 1536MB | Mein Numbercruncher, sauschnell |
Athlon 2200+ | 1800 | 256MB | Wird mein neuer Server | |
AMD K6-III | lemurbootp | 450 | 128MB | keine HD, Netboot only |
Gerade mit dem K6-III könnte es interessant werden, da der Rechner keine eigene Festplatte mehr hat (Netboot) und alles über das Netz ziehen muß. Mal sehen ob sowas noch eine Compile-unterstützung sein kann oder nur noch eine Bremse, die man besser weglässt.
Desweiteren bringt ccache
eine ganze Menge Speedup, gerade wenn alle Sourcen erneut compiliert werden werden müssen.
Aber dazu später mehr...
Frische Änderungen (All) | Edit SideBar | Zuletzt geändert am 14.02.2010 12:19 Uhr | Seite Bearbeiten | Seitenhistorie |
Powered by PmWiki |