Emerge beschleunigen

[Bearbeiten] Schnelleres Dateisystem(image)

Es gibt auch die Möglichkeit ein Extraimage anzulegen, welches ReiserFS(3/4) enthält. Dies lohnt sich vor allem bei ext(2/3).

Zuerst muss man eine Datei erzeugen, die das Image aufnimmt:

Mittels mkreiserfs wird darauf ein Filesystem erzeugt. Einhängen kann man es mit:

Nun nur noch ein emerge sync, und fertig.

Im Test mit ReiserFS3 auf ext3 war ein merklicher Geschwindigkeitsvorteil zu spüren. Am Besten ist es natürlich extra für /usr/portage eine echte Partition anzulegen, besonders dann, wenn man Reiser4 benutzen möchte.

[Bearbeiten] Kompilierung beschleunigen

Dazu gibt es mehrere Möglichkeiten, die man kombinieren kann.

[Bearbeiten] Ccache

Bei einem Software-Update ändert sich nicht der komplette Quelltext, sondern meist nur ein kleiner Teil. Es ist vorteilhaft, den schonmal kompilierten Teil wieder zu benutzen und nur die geänderten Quelltexte neu zu übersetzen. Dies erledigt Ccache, es überprüft, ob Teile des Quelltextes schon einmal übersetzt wurden und kopiert diese bei Übereinstimmung aus einem eigenen Cache heraus.

[Bearbeiten] Installation

Dazu installiert man dev-util/ccache :

[Bearbeiten] Konfiguration

Der Cache ist standardmäßig 500 MB groß. Es empfiehlt sich daher, ihn bei Bedarf zu vergrößern. Um Ccache beim emergen zu benutzen und die Cachegröße festzulegen, muss man die /etc/make.conf ändern:

FEATURES="ccache"
CCACHE_SIZE="2G"

Das G bedeutet Gigabyte, analog dazu ist M Megabyte. Mit ccache -s kann man Statistiken abrufen.

Und falls das Verzeichnis /var/tmp/ccache noch nicht besteht, erstellt man es, setzt die Berechtigungen und stellt sicher, dass ccache es auch benutzt.

Sollte man darauf eine Fehlermeldung erhalten die mit "ImportError: No module named portage_db_template" endet. So nun folgendes ausführen :

[Bearbeiten] Distcc

Gentoo hat einen Artikel über:

Distcc

Wenn man mehrere Rechner verwendet, kann man diese beim Kompilieren benutzen. Dies beschleunigt den emerge-Vorgang in der Weise, dass Distcc Teile des Quelltextes an die anderen Rechner schickt und fertig kompiliert zurückerhält. In der Zwischenzeit kann der Rechner weiterkompilieren.

[Bearbeiten] Installation

Vor der Installation sollten die aktiven USE Flags geprüft werden. Die USE Flags von sys-devel/distcc  sind:

• avahi - Aktiviert die Unterstützung für net-dns/avahi  für eine automatische Netzwerkkonfiguration.
• gnome - Installiert ein GNOME Dienstprogramm.
• gtk - Installiert ein GTK+ Dienstprogramm.
• hardened - Erhöht die Sicherheit auf Kosten von Funktion und Leistung.
• ipv6 - Aktiviert die Unterstützung für Internet Protocol Version 6.
• selinux - Unterstützt das Sicherheitskonzept SELinux.
• xinetd - Aktiviert xinetd Super-Server Unterstützung.

Nun installiert man distcc:

[Bearbeiten] Konfiguration

Nun muss man folgendes ausführen, damit man distcc generell nutzen kann:

Host sind die IP-Adressen der beteiligten Rechner. Diese Informationen werden in /etc/distcc/hosts gespeichert. Diese kann man seinen Bedüfnissen anpassen:

localhost/2
192.168.0.1/3

Die Zahlen hinter localhost und 192.168.0.1 geben an, wieviel Instanzen an die beteiligten Rechner geschickt werden. Die Summe sollte MAKEOPTS entsprechen. Dies dient der besseren Berücksichtigung der Rechenpower.

Damit Portage distcc benutzt, muss man wie folgt die /etc/make.conf ändern:

FEATURES="distcc"
MAKEOPTS="-jN"

N wird berechnet nach der Anzahl der CPUs +1. Häufig wird bei der Berechnung von der doppelten Anzahl von Prozessoren ausgegangen. Bei einer Anzahl von zwei beteiligten Rechnern wäre das entweder -j3 oder -j5. Bei der Verteilung der Aufgaben über das Netzwerk ist es sinnvoll diesen Wert höher anzusetzen, als dem vorgeschlagenen Wert für Ein-Platz Systeme. Ein Wert zwischen 10-15 ist hier sinnvoll, dieser kann nun auch viel gezielter auf die Leistungen der verschiedenen Rechner aufgeteilt werden (mit --set-hosts). Bei der Aufteilung ist zu Beachten, dass der 'Hauptrechner' jede Datei erst pre-compilen muss, eine geeignete Aufteilung bei zwei gleichstarken Rechern wäre also z.B.: "localhost/5 192.168.0.123/10".

Konfiguration der beteiligten Rechner Die beteiligten Rechner müssen noch kurz konfiguriert werden, hier wird in /etc/conf.d/distccd folgendes eingetragen:

DISTCCD_OPTS="${DISTCCD_OPTS} --allow 192.168.0.123

Für jeden beteiligten Rechner muss solch eine Zeile eingefügt werden, die IP muss natürlich angepasst werden.

Damit distcc genutzt werden kann, muss der Hintergrunddienst gestartet werden. Auch kann man ihn automatisch beim Booten starten lassen:

Man sollte den distcc Guide beachten.

[Bearbeiten] Icecream

Ähnlich wie DistCC (oben beschrieben) ist auch Icecream dazu gedacht, Daten über das Netzwerk zu verteilen um sie zu kompilieren.

Icecream hat allerdings ein paar Vorteile. Diese sind z.B. dass die eingesetzte Version des gcc nicht mehr eine so große Rolle spielt, wie noch mit DistCC. Die MAKEOPTS- und CHOST-Einstellungen werden automatisch übermittelt. Außerdem ist es leichter zu konfigurieren, da es auf einem Client-Server-Modell beruht.

Das sieht dann in der Praxis folgendermaßen aus: Auf dem Server läuft bereits Icecream, jeder Client, der den Icecream Dienst nun startet, meldet sich automatisch am Server an, der Benutzer muss nicht einmal die IP des Servers kennen.

[Bearbeiten] Installation

Da sys-devel/icecream  im Moment noch maskiert ist, muss das Ebuild noch demaskiert werden:

Nun installiert man icecream:

[Bearbeiten] Konfiguration

Da sich die Konfiguration von Client und Server nur in einem Punkt unterscheiden, werde ich an der entsprechende Stelle darauf hinweisen.

# N sollte mindestens die Anzahl der virtuellen Prozessoren
# im Cluster betragen. Größere Zahlen bringen nicht viel, da
# Icecream die parallelen Prozesse auf ICECREAM_MAX_JOBS
# (maximal die Anzahl der Prozessoren) beschränkt.
MAKEOPTS="-jN"
 
# Portage veranlassen mit Icecream zusammen zuarbeiten.
PREROOTPATH="/usr/lib/icecc/bin"

# Icecream veranlasse,n mit make zusammen zuarbeiten.
# Sollte von Hand in die Datei eingetragen werden,
# da echo die Variable gleich auflöst.
PATH="/usr/lib/icecc/bin:${PATH}"

# Soll dies unser Server werden, ist hier "yes" einzutragen.
ICECREAM_RUN_SHEDULER="no"
 
# Hier die maximalen Jobs eintragen. Wenn nichts eingetragen
# wird, verwendet Icecream die Anzahl der im Cluster
# verfügbaren virtuellen Prozessoren.
ICECREAM_MAX_JOBS=""

Damit icecream genutzt werden kann, muss der Hintergrunddienst gestartet werden. Auch kann man ihn automatisch beim Booten starten lassen:

Zusatz Netzwerkkonfiguration: Falls eine Firewall existiert, müssen auf dem Server die Ports TCP/8765 für iceccd und UDP/8765 für Broadcast offen sein, optional TCP/8766 für Telnet. Der Client braucht den Port TCP/10245.

Zudem braucht Icecream Broadcast Pings, um festzustellen, welche Maschinen (egal ob Client oder Server) verfügbar sind. Das geschieht sogar noch, bevor die offenen Port ins Spiel kommen. Deshalb muss

# Ignore ICMP broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 0

sein, und allfällige Firewalls müssen ICMP Echo (eben ping-Nachrichten) durchlassen.

[Bearbeiten] Tmpfs

tmpfs ist ein Dateisystem, welches im Kernel aktiviert werden muss. Es dient dazu ein virtuelles Dateisystem in den Verzeichnisbaum einzuhängen, welches komplett im Arbeitsspeicher läuft. Man kann so /var/tmp/portage im Arbeitsspeicher laufen lassen und beschleunigt dadurch emerge, da es temporäre Dateien nicht mehr in die vergleichsweise sehr lahme Festplatte schreiben muss. Das ganze empfiehlt sich natürlich erst bei einer ausreichenden Menge Arbeitsspeicher, mindestens ein GB sollte vorhanden sein.

Nach einem Neustart kann man die Funktion nutzen:

Je größer das Paket ist, desto mehr Arbeitsspeicher wird für /var/tmp/portage benötigt. X.Org braucht ca. 850 MB zum Beispiel. Wenn Portage abbricht, war der Platz einfach zu wenig. Man sollte Arbeiten mit tmpfs beachten. Am besten kontrolliert man, wie stark die RAMDISK ausgelastet ist, mit dem Befehl:

wobei hier /var/tmp/portage mit portage eine Datei gemeint ist.

Um zu überprüfen, wie groß /var/tmp/portage mindestens sein muss, und in der Annahme, dass /var/tmp/portage ursprünglich ein Verzeichnis war, dient folgender Befehl:

wobei hier /var/tmp/portage mit portage ein Verzeichnis gemeint ist.

[Bearbeiten] Hinweise

/var/tmp/portage oder sonstige extrem selten oder einmalig benutzten Dateien in den Arbeitsspeicher zu legen, hebelt den Cache des Systems aus. Wenn nämlich ein Quellpaket (auf Disk) entpackt wird, liegt es bereits im Cache vor (soviel wie rein passt). Leseoperationen auf die Quellcode-Dateien sind deshalb schon signifikant beschleunigt. Desweiteren werden auch die Daten in tmpfs in den langsamen Swapspeicher auf Platte ausgelagert, wenn man zuwenig RAM frei hat, was oben angenommenen Vorteil wieder aushebelt. Oben beschriebene Geschwindigkeitsgewinne sind also nur im besten Fall zu erwarten und von vielerlei Faktoren abhängig und werden durch Reduktion von Cache und Verringerung des verfügbaren RAM sehr teuer erkauft. tmpfs verringert praktisch "nur" die Wartezeit auf den langsamen Disk-IO. Diese Wartezeit kann man jedoch auch dadurch füllen, dass man mehrere gcc-Jobs parallel startet. Beispielsweise ist dies der Grund, weshalb man make den "-jN" Schalter mitgibt und N idR etwas größer wählt als die Anzahl der CPUs im Rechner. Damit ist gewährleistet, dass wenn ein gcc-Job fertig ist und auf eine Schreib- oder Leseoperation wartet (lesen von Quellcode, schreiben von Binärcode), andere rechenintensive gcc-Jobs die Wartezeit der CPU mit Berechnungen füllen. Um zu schauen ob tmpfs Vorteile bringt, hilft das Tool vmstat (oder iostat). Gestartet mit "vmstat 1" ("iostat 1") wird die Ausgabe jede Sekunde aktualisiert. Wichtig ist die letzte Spalte, welche den Anteil der Wartezeit auf IO angibt. Steht hier eine 0, so wartet die CPU nicht auf IO. Steht hier eine 50, dann wurde 50% der letzten Sekunde (also eine halbe Sekunde) auf IO gewartet. Nach meinen Erfahrungen ist der IO-Anteil so gut wie immer 0% oder nahe 0%. Nach Tests hat mir das portage-Temp auf tmpfs einen Performancegewinn von ca. 2.5% gebracht, bei manchen Paketen überhaupt keinen Gewinn. Dies ist aber nahezu vollständig der Overhead, der durch die nicht-parallelisierten Operationen entsteht (z.B. entpacken, patchen, configure, Installation, usw.). Man muss also genau prüfen, ob die Optimierung nicht nur subjektiver Natur ist.

[Bearbeiten] Schneller Suchen mit Eix

Die schnellste Suche nach Paketen bietet Eix. Vor der Installation sollten die aktiven USE Flags geprüft werden. Die USE Flags von app-portage  sind:

• bzip2 - (Veraltet) Liest die enviroment.bz2 aus, um das Repository zu ermitteln.
• debug - Generiert zusätzliche Dateien, die bei der Fehlersuche helfen.
• doc - Installiert weitere Dokumentationen.
• hardened - Erhöht die Sicherheit auf Kosten von Funktion und Leistung.
• nls - Unterstützung für Lokalisierung.
• optimization - Verwendete die empfohlenen CFLAGS vom Software-Hersteller anstatt der eigenen.
• sqlite - Aktiviert Unterstützung für Portages sqlite Backend.
• strong-optimization - Experimentelle Optimierungen.
• tools - Erstellt Binärprogramme aus einigen Skript-Programmen, um deren Ausführung zu beschleunigen. Lohnt sich nur bei extrem häufigen Aufrufen.
• zsh-completion - Eingabe-Vervollständigung in zsh Shell.

Nun installiert man eix:

Danach noch ein eix-update und die Suche kann beginnen. Es unterstützt mehrere Suchvarianten, ein eix -h zeigt die Hilfe an, wobei ein einfaches eix alle Pakete aufzeigt. Eix bietet die Möglichkeit emerge --sync und eix-update in einem Ritt durchzuführen, in Zukunft reicht:

Dabei wird einem praktischerweise angezeigt, welche Pakete aus dem Portage Baum entfernt oder hinzugefügt wurden und welche Updates es gab.

[Bearbeiten] Links

• DistCC Guide

[Bearbeiten] Lizenz

Dieser Artikel wurde unter der GNU-Lizenz für freie Dokumentation veröffentlicht. Es ist erlaubt, diesen Artikel unter den Bedingungen der GNU-Lizenz für freie Dokumentation, Version 1.2 oder einer späteren Version, veröffentlicht von der Free Software Foundation, zu kopieren, zu verbreiten und/oder zu modifizieren. Es gibt keine unveränderlichen Abschnitte, keinen vorderen Umschlagtext und keinen hinteren Umschlagtext. Zusätzlich ist der Artikel unter der Creative Commons Attribution-Share Alike 3.0 lizenziert, bitte beachte Gentoo Linux Wiki:Urheberrecht.