# Im RAM Kompilieren

## EOF

Ich habe gerade das folgende Howto gefunden

http://www.sysalyser.de/?menue=howtos&submenue=software&thema=compile_in_ram

Ich habe 4 GB und hätte dazu noch einige Fragen.

- Lohnt sich das ? Ich sehe desöfteren mit "top", dass die CPUs beim Kompilieren nicht ausgelastet sind.

- Wie sorge ich dafür, dass /var/tmp/portage nach der Kompilation von jedem Paket gelöscht wird  (wegen emerge -u world)?

- Gibt es ein Skript, was im Falle der Speicherknappheit auf Festplattenkompilation umschaltet?

- Gibt es sonst irgendwelche Gefahren, die mit dieser Vorgehensweise die Stabilität meines Systems gefährden können?

- Wer von euch kompiliert im RAM?  

PS: Hab ein Thinkpad T400 auf amd64 laufen.

----------

## 69719

zu 1. ja, da der Festplattenzugriff wesentlich länger dauert als der im Arbeitsspeicher

zu 2. wenn du ein tmpfs auf diesen Ordner mountest, so ist dieser Ordner nach jedem neustart leer

zu 3. wohl kaum, dass müßte Portage erledigen

zu 4. es könnte passieren, dass dein System anfängt zu swappen, falls du mehr Speicher zuordnest als du an Arbeitsspeicher besitzt

zu 5. ich

----------

## Hollowman

Hi

Ich compiliere alle Gentoo Systeme im RAM. Das merkt man schon. ccache bringt auch noch ne ganze Ecke. Und beim neuen Portage die -j Option.

Einfach in der /etc/fstab folgenden Eintrag machen.

tmpfs                   /tmp            tmpfs           rw,noatime      0 0

tmpfs                   /var/tmp/portage     tmpfs      rw,noatime      0 0

Dann einmal booten. Dann hast du tmp im RAM und den Portage tmp Ordner. Die können beide bei Bedarf 1,5GB groß werden. Wenn das dein RAM nicht her gibt wird geswapt. Ich hab aber bis jetzt noch fast nicht gehabt was sich nicht im RAM compilieren ließ. Was nicht ging war icedtea6 und OpenOffice (da hab ich es erst garnicht versucht).

Und ich hab zu Hause nur 3GB Ram. Nach dem compilieren ist der Ram ja dann wieder leer.

Sebastian

----------

## Necoro

Ich benutz das auch schon länger ... da mein guter alter T42 aber nur 1GB RAM besitzt, muss ich es bei einigen großen Paketen abschalten =/

Deine Frage mit dem /var/tmp/portage leeren verstehe ich nicht wirklich. Normalerweise macht Portage das automatisch, es sei denn du hältst es davon ab ("keepwork" in FEATURES)

----------

## EOF

 *Necoro wrote:*   

> Ich benutz das auch schon länger ... da mein guter alter T42 aber nur 1GB RAM besitzt, muss ich es bei einigen großen Paketen abschalten =/
> 
> Deine Frage mit dem /var/tmp/portage leeren verstehe ich nicht wirklich. Normalerweise macht Portage das automatisch, es sei denn du hältst es davon ab ("keepwork" in FEATURES)

 

Naja ich bin gerade nicht an einer Gentoobox ...

Ich werde das heute Abend mal probieren. 

Wo wir gerade von RAM reden. Ich habe gelesen, dass es etwas bringen soll, wenn man die lib-Verzeichnisse

im RAM hält. 

Ich verstehe das nicht, da der Speichermanager doch schon häufig genutze Dateien ins RAM läd. Wieso sollte

das was bringen (ausser beim ersten Programmstart)?

Danke nochmal für die schnelle Antworten.

----------

## fangorn

Nun, solche "Performancetips" gelten für eine bestimmte Anwendung. Wenn man den Rechner nur hochfährt, sich einloggt, den Browser startet und danach den Rechner wieder ausschaltet dann kann das was bringen. Erststart und so. Prinzipiell gilt: wenn die Daten im RAM liegen ist der Zugriff schneller. Nicht umsonst bieten Livecds die Option, sich komplett in den RAM zu laden. Kannst du (im Prinzip) auch mit jeder Gentoo installation machen. Das wuppt dann richtig wenn du genug RAM hast. Nur ob sich der Aufwand lohnt muss jeder selber entscheiden.   :Twisted Evil: 

----------

## papahuhn

 *Hollowman wrote:*   

> Ich compiliere alle Gentoo Systeme im RAM. Das merkt man schon. ccache bringt auch noch ne ganze Ecke.

 

Das passt aber nicht so ganz zusammen, oder?

----------

## py-ro

ccache und ramdisk passen nicht wirklich zusammen, weil dann ccache in seinem Cache auf der HDD nachschaut. Was man mit der RAM Disk ja vermeiden wollte.

In einer Ramdisk kompilieren war ich auch mal ein Fan von, allerdings bringt es heute relativ wenig. Die meisten Builds passieren eh schon im RAM, durch caches. Und bei den richtig großen muss man dann auch richtig viel RAM haben.  Außerdem gehen die RAM Disks nicht so effizient mit dem Speicher um, wie man es gerne hätte.

Es ist eine nette Spielerei, aber mehr auch nicht, meiner Meinung nach.

Ein Hinweis noch, falls du es probierst schraube die Anzahl an Inodes in der RAM Disk, per Parameter, etwas nach oben, sonst kann es da eng werden.

Py

----------

## SvenFischer

ccache sucht identische bereits kompilierte Sachen und ersetzt diese dann. Klar bringt das etwas, ist aber meiner Erfahrung nach dann besonders sinnvoll, wenn ein und dasselbe Programmpaket wiederholt kompiliert, dann rauscht das wesentlich schneller durch.

----------

## musv

 *py-ro wrote:*   

> ccache und ramdisk passen nicht wirklich zusammen, weil dann ccache in seinem Cache auf der HDD nachschaut. Was man mit der RAM Disk ja vermeiden wollte.

 

Eigentlich dachte ich immer, dass dafür unter /var/tmp/ccache oder ~/.ccache eine Unmenge an Dateien angelegt werden. Allerdings hab ich mich in letzter Zeit ziemlich dumm und dämlich gewundert. Da ich mittlerweile 4 GB Ram hab, compilier ich auch das meiste im Ram. Ziel ist bei mir neben der (kaum spürbar höheren) Geschwindigkeit, dass ich eine unnötige Fragmentierung vermeiden will. 

Tja, und ccache benutz ich nur für die großen Brocken (gcc, kdelibs, openoffice, glibc, usw.) Problem dabei ist nur, dass bei ccache -s die Zahl der cache-misses ca. 11x so groß ist wie die Zahl der Treffer. Ich bin mittlerweile kurz davor ccache ganz vom Rechner runterzuschmeißen. Wobei OpenOffice auch nicht wirklich cache-Treffer hatte. Und das kann ich mit den 4 GB nicht im Ram compilieren. Zumindest merk ich mittlerweile keinen Unterschied, wenn ich ccache verwende und wenn nicht. 

Verwunderlich dabei ist, dass ccache auf meinem alten Rechner bei einem Recompile von z.B. OpenOffice echt was gebracht hatte. 

Neucompilieren 10 Stunden - Recompilieren bei USE-Flag-Änderung weniger als 3 Stunden

Ach ja, weil das hier nicht wirklich so rauskam: 

Was passiert, wenn die RAM-Disk zum Compilieren nicht ausreicht? Ganz einfach, dann kriegst du 'ne Fehlermeldung, dass das Laufwerk voll ist. Dann darfst du entweder die Ramdisk umounten oder falls vorhanden, andere Einträge darin löschen. Auf alle Fälle darfst du den Salat dann noch mal neu compilieren. 

Die bisher größten Brocken (Paket - Plattenbedarf bei Compilieren (arg gerundet)):

OpenOffice - 5-8GB

kdelibs:4 - 1.5GB

gcc - fast 2GB (da bin ich mir aber nicht mehr sicher)

 *EOF wrote:*   

> Lohnt sich das ? Ich sehe desöfteren mit "top", dass die CPUs beim Kompilieren nicht ausgelastet sind. 

 Was hast jetzt die CPU-Auslastung mit dem Ram zu tun?

 *EOF wrote:*   

> Wie sorge ich dafür, dass /var/tmp/portage nach der Kompilation von jedem Paket gelöscht wird (wegen emerge -u world)?

 

Brauchst du theoretisch nicht. Sofern das compilierte Paket sauber durchläuft, wird das Temp-Verzeichnis dieses Paketes gelöscht. Probleme gibt's dann, wenn eine Reihe an Paketen abbricht. Beim Umounten / Runterfahren des Rechners wird die Ramdisk aber sowieso entfernt. Die Müllsorgen hast du also nur temporär. 

 *EOF wrote:*   

> Gibt es ein Skript, was im Falle der Speicherknappheit auf Festplattenkompilation umschaltet? 

 Nö, Compilieren im Ram ist ja nicht mal offizieller Bestandteil der Gentoo-Installation. Außerdem müsstest du dann sämtliche Inhalte der Ram-Disk auf die Festplatte verschieben. Das wäre beim Compilieren zu aufwändig. 

 *EOF wrote:*   

> Gibt es sonst irgendwelche Gefahren, die mit dieser Vorgehensweise die Stabilität meines Systems gefährden können?

 Nö

 *EOF wrote:*   

> Wer von euch kompiliert im RAM?

 ich

Was ich wärmstens empfehlen kann: 

Den Portage im squashfs mit unionfs ablegen. Davon bin ich mittlerweile begeistert. Ich hab dabei die erste Variante (Kernel-Patchen) benutzt. Muss ich wegen Reiser4 sowieso machen. Nur bei den Overlays - sofern man die im Portage-Verzeichnis lassen will - muss ein man paar kleine Dinge beachten. Vielleicht schreib ich das mal ins Wiki noch mit rein. 

Und ansonsten ist Prelinking nicht übel.

----------

## Necoro

 *musv wrote:*   

> Die bisher größten Brocken (Paket - Plattenbedarf bei Compilieren (arg gerundet)):
> 
> OpenOffice - 5-8GB
> 
> kdelibs:4 - 1.5GB
> ...

 

Also gcc kann ich bei 1GB RAM locker in ner 700MB Ramdisk bauen - sogar ohne swappen...

----------

## Gladdle

 *Hollowman wrote:*   

> Einfach in der /etc/fstab folgenden Eintrag machen.
> 
> tmpfs                   /tmp            tmpfs           rw,noatime      0 0
> 
> tmpfs                   /var/tmp/portage     tmpfs      rw,noatime      0 0

 

Bei mir kommt da eine Fehlermeldung. Sollte es nicht so heissen:

```
none                   /tmp            tmpfs           rw,noatime      0 0

none                   /var/tmp/portage     tmpfs      rw,noatime      0 0
```

Oder was mache ich falsch? (mount: bad fs type, bad option or bad superblock on tmpfs)

----------

## Necoro

Also bei mir steht

```
tmpfs         /var/tmp/portage tmpfs   noatime,size=1200M      0 0
```

(Hinweis: ist nicht auf dem Laptop  :Wink:  - deswegen nicht über die andere Größe wundern)

----------

## Gladdle

Wow ... schnelle Antwort. Ich hatte einen rechtschreibfehler drin, deshalb ging es nicht. Warum nicht auf dem Notebook? Es hat doch 3 GB Ram ohne Shared Mem, muesste doch gehen, oder?

----------

## 69719

 *Gladdle wrote:*   

>  *Hollowman wrote:*   Einfach in der /etc/fstab folgenden Eintrag machen.
> 
> tmpfs                   /tmp            tmpfs           rw,noatime      0 0
> 
> tmpfs                   /var/tmp/portage     tmpfs      rw,noatime      0 0 
> ...

 

Eventuell was im Kernel vergessen?

----------

## Necoro

 *Gladdle wrote:*   

> Warum nicht auf dem Notebook?

 

Bezog sich auf _meinen_ Laptop ... weil ich oben was von 700MB erwähnt - und hier nun 1200 stehen - wollte Nachfragen, Hinweisen u.ä. zuvorkommen  :Wink: 

----------

## Gladdle

@ escor und Necoro

Wie gesagt, ich hatte mich vertippt. Klappt so wunderbar!

@Necoro

Tut mir leid, da hatte ich Dich wohl falsch verstanden!

Funktioniert nun und compiliert auch schon (ScummVM ^^)

----------

## musv

 *Gladdle wrote:*   

> ... (ScummVM ^^)

 

Mein Rekord liegt bei irgendwas um die 25 Minuten für Day of the Tentacle.

----------

## EOF

Hat eigentlich jemand Zeitmessungen beim Kompilieren einiger Pakete gemacht (mit und ohne RAM)? 

Ich hatte gestern nur mal schnell eine Update gemacht und dabei gab es keinen 

gefühlten Geschwindigkeitsvorteil. Die CPU-Auslastung ist ebenfalls nicht wesentlich höher. 

Ich werde demnächst mal die PORTAGE_NICENESS runtersetzen  :Smile: .

Ausserdem hab ich noch dieses IO-Problem, dass beim Kopieren oder Downloaden  von 

Dateien auf die Performance schlägt.

----------

## gimpel

 *EOF wrote:*   

> - Lohnt sich das ? Ich sehe desöfteren mit "top", dass die CPUs beim Kompilieren nicht ausgelastet sind.

 

Man setze MAKEOPTS -jx, wobei x=anzahl cores+1

```
# grep MAKEOPTS /etc/make.conf

MAKEOPTS="-j3"
```

 *Necoro wrote:*   

>  *musv wrote:*   Die bisher größten Brocken (Paket - Plattenbedarf bei Compilieren (arg gerundet)):
> 
> OpenOffice - 5-8GB
> 
> kdelibs:4 - 1.5GB
> ...

 

Klingt nach einem 32bit System. Bei einem multilib amd64 System kannst du fast das doppelte rechnen.

----------

## py-ro

Das mit den Cores*2+1 ist eine gute Faustregel.

Bei mir habe ich z.B. auf einem Athlon64x2 4200+ bei 6 das Optimum, durch langes testen mit mehr und weniger herausgefunden.

Ich habe Hier Phenom Quad Cores die lagnweilen sich noch bei 16, aber wohl eher, weil die meisten Aufgaben sich nicht soweit zerlegen lassen.

Py

----------

## gimpel

 *py-ro wrote:*   

> Das mit den Cores*2+1 ist eine gute Faustregel.

 

Cores*2+1? Oha. Laut handbook war's Cores+1.

Aber da geht probieren echt über studieren, richtig.

----------

## py-ro

Nein hab mich vertan   :Embarassed:   Cores+1 war richtig.

Py

----------

## 69719

Da wir nun bei den MAKEOPTS angekommen sind ... http://jolexa.wordpress.com/2008/07/24/gentoo-portages-new-jobs-feature/

----------

## EOF

 *escor wrote:*   

> Da wir nun bei den MAKEOPTS angekommen sind ... http://jolexa.wordpress.com/2008/07/24/gentoo-portages-new-jobs-feature/

 

Womit man wieder mehr RAM bräuchte um beim Thema zu bleiben. Denn wenn man mehrere Pakete kompilieren will muss man die auch entpacken ...

Das wäre aber sonst ein toller Tipp.

@gimpel

MAKEOPTS="-j3"

nutze ich natürlich schon.

----------

## Hollowman

Hi

Ich hab die MAKEOPTS auf 3 stehen und häng beim emergen immer ein -j 3 an. Dann hat die Kiste richtig was zu tun.

Sebastian

----------

## Martux

 *escor wrote:*   

> Da wir nun bei den MAKEOPTS angekommen sind ... http://jolexa.wordpress.com/2008/07/24/gentoo-portages-new-jobs-feature/

 

Also das mit load-average kapier ich nicht so richtig... Was ist denn da ein vernünftiger Wert? (Quadcore CPU)

EDIT: Ach so, ich benutze auch tmpfs für /var/tmp/portage und ccache. (Ccache ist auf ~arch, wo es öfter Mal r1-2-3 releases sowie geänderte Useflags gibt sicher sinnvoll).

----------

## musv

Hier hab ich grad noch was zu ccache gefunden:

http://blog.flameeyes.eu/2008/06/21/debuking-ccache-myths

Besonders interessant war darin der Abschnitt (weiter unten):

 *Duncan  about 12 hours later: wrote:*   

> Talking about compiling into tmpfs, those of us with PORTAGE_TMPDIR pointed at tmpfs only have to worry about ONE of those writes to disk you mentioned, the ccache write (caching it to disk is sort of the point), since the result written to PORTAGE_TMPDIR is usually only an intermediate result anyway, and deleted before the final qmerge to the live system filesystem on disk. Not having to write and delete all those intermediate results files makes a pretty big difference! =8^)

 

Tja, heißt jetzt also: 

Entweder ccache oder tmpfs. Beides scheint nicht zu gehen.

----------

## SinoTech

 *musv wrote:*   

> Hier hab ich grad noch was zu ccache gefunden:
> 
> http://blog.flameeyes.eu/2008/06/21/debuking-ccache-myths
> 
> Besonders interessant war darin der Abschnitt (weiter unten):
> ...

 

Doch klar, das eine hat mit dem anderen ja eigentlich nichts zu tun. Temporäre Dateien die beim build entstehen werden so oder so unter "PORTAGE_TMPDIR" abgelegt, ganz egal ob sie direkt vom compiler stammen oder von ccache.

Cheers,

Sino

----------

