Emerge beschleunigen

Aus Gentoo Linux Wiki

Es gibt mehrere Ansätze um das Emergen zu beschleunigen. Diese soll dieses Howto aufzeigen.

[Bearbeiten] Downloadzeiten verringern

Man kann Zeit einsparen, indem man nur die Veränderungen eines Paketes herunterladen lässt. Auch beim Syncen lässt sich Zeit sparen. Da beides primär den Effekt hat die Downloadmenge zu verringern, wurde beides in einem extra Howto zusammengefasst.

Auch ist die Nutzung von Portage via NFS vorteilhaft bei mehreren Rechnern mit installiertem Gentoo.

[Bearbeiten] Schnelleres Filesystem(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:

head -c<GROESSE_IN_BYTE> </dev/zero >portage.image

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

mount -o loop portage.image /usr/portage

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] Warnung

Die Performance von ReiserFS3 verschlechtert sich mit jedem Update des Portage Trees.

[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. emerge -av ccache

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"

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.

cd /var/tmp
mkdir ccache
chown portage:portage ccache
chmod 775 ccache
echo "CCACHE_DIR=\"/var/tmp/ccache\"" >> /etc/env.d/99local
env-update
source /etc/profile

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

rm -rf /etc/portage/modules
emerge --metadata

[Bearbeiten] 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. Installieren kann man es mit: emerge -av distcc

Nun muss man folgendes ausführen damit man distcc generell nutzen kann: distcc-config --install
distcc-config --set-hosts "localhost host1 host2 ..."

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 versch. 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.

Nun muss man auf allen beteiligten Rechnern den distccd-Dämon starten: /etc/init.d/distccd start Falls man den Dienst dauerhaft laufen lassen möchte zusätzlich: rc-update -a distccd default

Notiz: Es sei angemerkt, dass wenn z.b. nur zwei Rechner benutzt werden und die Leistung zwischen beiden sich stark unterscheidet, die Nutzung von distcc auf dem schnelleren Rechner unter Umständen emerge ausbremsen kann, da öfters der Schnellere auf den Langsameren warten muss.

Wenn man auf einem Rechner distcc nicht nutzen will, muss man lediglich distcc aus der FEATURES-Variable in der /etc/make.conf entfernen.

Man kann die Nutzung anderer Rechner durch folgende Kommandos überwachen:

DISTCC_DIR="/var/tmp/portage/.distcc/" distccmon-text N

N ist hier die Zeitspanne, nach der die Ansicht aktualisiert werden soll. Alternativ kann auch ein X-Programm gestartet werden:

DISTCC_DIR="/var/tmp/portage/.distcc/" distccmon-gui

Man sollte den distcc Guide beachten.

Kompilieren mit Gentoo und FreeBSD als weiteren Rechner

Beim parallelen Kompilieren mit FreeBSD als weiterer Rechner muss unter FreeBSD nur ein symlink gesetzt werden. Natürlich muss vorher distcc installiert und konfiguriert werden.

Wenn unter gentoo CHOST="i686-pc-linux-gnu" ist und gcc41 verwendet wird, dann sollte unter FreeBSD der gcc41 installiert werden und folgende links gesetzt werden:

 ln -s /usr/local/bin/gcc41 i686-pc-linux-gnu-gcc
 ln -s /usr/local/bin/gcc41 i686-pc-linux-gnu-g++

Probleme bein parallelen kompilieren mit Gentoo als Client und FreeBSD als Server:

[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

Derzeit ist Icecream noch maskiert, um es verfügbar zu machen, reicht ein:

echo "sys-devel/icecream ~x86" >> /etc/portage/package.keywords

Danach kann man es wie gewohnt mit:

emerge -av sys-devel/icecream

installieren.

[Bearbeiten] Konfiguration

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

MAKEOPTS="-jN"                   # Anzahl der Prozessoren im Cluster +1
PREROOTPATH="/usr/lib/icecc/bin" # Icecream veranlassen mit Portage zusammen zuarbeiten

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

ICECREAM_RUN_SHEDULER="no"       # Soll die unser Server werden ist hier "yes" einzutragen
ICECREAM_MAX_JOBS="N"            # Hier die maximalen Jobs eintragen, also das was vorher
                                 # bei MAKEOPTS="-jN" stand

Das war es eigentlich schon mit der Konfiguration. Der einzige Nachteil ist halt, dass der Server immer laufen muss aber das sollte kein Problem darstellen. So, jetzt auf jeder Maschine einmal ein:

/etc/init.d/icecream start

Und sich am neuem Cluster erfreuen.

--Moriarty 05:03, 8. Jul. 2007 (UTC)

[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 Ram läuft. Man kann so /var/tmp/portage im Ram 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 Ram, mindestens ein GiBi sollte vorhanden sein. Um tmpfs zu nutzen muss man folgendes im Kernel aktivieren:

File systems  --->
 Pseudo filesystems --->
  [*] Virtual memory file system support (former shm fs)

Wie man seinen Kernel editiert und kompiliert erfährt man im Kernel Howto. Nach einem reboot kann man das Feature nun nutzen: mount -t tmpfs tmpfs /var/tmp/portage

Dies mountet die Hälfte des Rams nach /var/tmp/portage. Um weniger oder mehr zu mounten, muss man die Option -o size=100M übergeben, wobei hier 100 MiB gemountet werden. Um den Platz wieder freizugeben muss man folgendes ausführen: umount -f /var/tmp/portage

Je größer das Paket ist, desto mehr Ram wird für /var/tmp/portage benötigt. Xorg braucht ca. 850 MiB 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:

df -h /var/tmp/portage

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

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

du -sh /var/tmp/portage

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

[Bearbeiten] Hinweise

/var/tmp/portage oder sonstige extrem selten oder einmalig benutzten Files und Daten in den RAM 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. Installiert ist es schnell mittels:

emerge eix.

Danach noch ein update-eix 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 update-eix in einem Ritt durchzuführen, in Zukunft reicht:

eix-sync

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

[Bearbeiten] Quellen

• Distcc Guide
• Arbeiten mit tmpfs
• speedhack-portage-2.1