Hallo Leute,

ich bastle zur Zeit etwas an meinem Laptop, um ihm noch etwas mehr Leistung abzuringen. Ich habe den RAM bereits von 1GB auf 2GB verdoppelt (für 17,-€, falls es vllt jemanden interessiert). Nach einiger Zeit sind die 2GB RAM dann auch komplett vom System in Beschlag genommen, davon sind ca. 350 MB fest vergeben, der Rest ist Cache.

Zuerst habe ich nun /tmp und /var/tmp mit tmpfs in den RAM gelegt, um Die Festplatte etwas zu entlasten und eventuell einen kleinen Geschwindigkeitsbonus zu erzielen. Dazu habe ich die entsprechenden Einträge in der /etc/fstab angelegt.

tmpfs    /tmp           tmpfs     defaults      0      0
tmpfs    /var/tmp       tmpfs     defaults      0      0

Das System läuft nach dem Reboot immernoch ganz normal und stabil.

Allerdings habe ich in einem Thread http://ubuntuforums.org/showthread.php?t=633776 folgende Konfiguration entdeckt:

# /tmp as a temporary file system
none /tmp tmpfs size=2G,nr_inodes=200k,mode=01777 0 0

Birgt diese Konfiguration irgendwelche Vorteile? Ich kann damit leider noch nicht so viel anfangen.

Werden die temporären Dateien von Firefox eigentlich auch dort abgelegt? Das ist bei mir glaube ich der größte Produzent kurzlebiger Daten. Oder gibt es vielleicht sonst noch Verzeichnisse, bei denen es sinnvoll sein kann, sie auszulagern?

Danach habe ich den Eintrag

vm.swappiness=0

an die /etc/sysctl.conf angehängt, damit der SWAP nur in Ausnahmefällen genutzt wird. Das sollte so dann ja OK sein.

So, jetzt das wichtigste: Ich möchte einen einen eigenen Kernel konfogurieren, um überflüssige Prozesse usw. von Bord zu werfen. Wie man das an sich macht, ist ja in zahllosen HOWTOs und Tutorials beschrieben. Ich würde nur gerne wissen, was eigentlich bei Aktualisierungen passiert. Meine erste Frage ist, ob ich die Aktualisierungen trotz einiger auskonfigurierter Dinge im Custom-Kernel noch gefahrlos einspielen kann. Und falls die Aktualisierungen eine neue Kernelversion enthalten, kann ich da einfach im GRUB meinen Kernel als Default setzen, oder kann es da auch Probleme mit aktuellerer Software geben?

Ehrlich gesagt habe ich nämlich keine Lust zu jeder neuen Kernelversion einen neuen Custom-Kernel bauen zu müssen. Ausprobieren werde ich es aber auf jeden Fall einmal.

Ja, falls euch sonst noch etwas einfällt, was vielleicht zu meinem Mini-Projekt "Raketenlaptop" beitragen könnte, würde ich das natürlich auch gerne wissen.

Vielen Dank schonmal soweit fürs lesen, ne antwort wäre klasse ^.^

zarcaphii schrieb:

Ehrlich gesagt habe ich nämlich keine Lust zu jeder neuen Kernelversion einen neuen Custom-Kernel bauen zu müssen. Ausprobieren werde ich es aber auf jeden Fall einmal.

Dir ist aber schon klar, dass die Kernelupdates wichtige Sicherheitspatches enthalten und du deshalb den Kernel jedesmal neu kompilieren solltest, wenn auch ne neue Version kommt. Ansonnsten kannst du immer den einmal kompilierten Kernel nehmen, da dürften keine Kompatiblitätsprobleme auftauchen. Und pass auf, was du deaktivierst, das führt manchmal zu sehr komischen Verhaltensweisen. Gerade wenn du Dinge rausschmeißen willst musst du mehrere Male den Kernel kompiliern und dich langsam vortasten: mal geht kein automount mehr mal ist irgend eine Hardware nichtmehr da ...

Warum nimmst du eigentlich nicht Gentoo oder Arch, die währen für deine Zwecke viel besser geeignet.

Das sind ja mehr oder weniger auch Schönheitsoperationen, die ich da mache. Wichtiger ist mir, dass mein System stabil läuft und im normalen Alltag einfach zu bedienen ist. Und Sicherheitsupdates gehen bei mir vor Kann man die Konfiguration auf neue Kernelversionen übertragen? Dann müsste man ja nur:

a) Updates (inkl. neuer Kernelversion) laden + installieren

b) Neue Kernelversion als Source laden

c) Mit vorhandenen Einstellungen kompilieren

d) Custom-Kernel installieren

Über Gentoo weiß ich nur, dass Pakete immer auf dem heimischen PC kompiliert und dann installiert werden. Das hat natürlich viele Vorteile. Dazu habe ich aber auch gelesen, dass man einiges noch von Hand nachjustiert werden muss. Ich habe zwar Spaß daran, neues auszuprobieren, aber wenn mal etwas schnell und problemlos laufen soll, ohne, dass man viel Hintergrundwissen braucht, dann habe ich bei Ubuntu glaube ich schon eine gute Wahl getroffen.

Mir ist heute aufgefallen, dass meine tmpfs Einstellung nicht so richtig zu funktionieren scheint.

# /etc/fstab: static file system information.
[...]
tmpfs	/tmp		tmpfs	defaults	0	0
tmpfs	/var/tmp	tmpfs	defaults	0	0

Ich habe eine CD gebrannt, dabei waren in /tmp 806 MB belegt. Der RAM hatte die üblichen ~380MB Auslastung (Systemmonitor). Also entweder funktioniert die tmpfs-Umleitung nicht oder der belegte Speicher wird nicht im Systemmonitor angezeigt. Zweiteres wäre allerdings komisch, weil das ja Daten sind, die auf jeden Fall im RAM sind. Kein Cache oder so.

Hat niemand eine Idee, wie ich rausfinden kann, wieso /tmp nicht wie gewollt im RAM landet?

zarcaphii schrieb:

Ich möchte einen einen eigenen Kernel konfogurieren, um überflüssige Prozesse usw. von Bord zu werfen.

Es gibt in einem laufenden Kernel keine überflüssigen Prozesse, und dein System wird im Regelfall auch nicht schneller, schlanker oder sonst irgendwie toller, wenn der Kernel selbst kompiliert wurde. Abgesehen vom Patchen oder Aktivieren bestimmter instabiler Funktionalität oder Debugging-Tools gibt es keinen Grund, den Kernel selbst zu kompilieren.

Wenn die Ausgabe von mount sagt, das /tmp im Arbeitsspeicher liegt, dann liegt es auch im Arbeitsspeicher. Allerdings wird eine tmpfs-Ramdisk iirc nicht als Anwendungsspeicher geführt, und zählt daher auch nicht zu den 380 MB.

/var/tmp ist im Übrigen laut FHS zum Speichern temporärer Dateien da, die einen Neustart überleben sollten oder gar müssen. Es ist daher eine ganz schlechte Idee, dieses Verzeichnis in den Arbeitsspeicher zu verlegen. Zudem bezweifele ich, dass das Verlegen von /tmp in eine Ramdisk sowie die Einstellung vm.swappiness = 0 den gewünschten Effekt, nämlich eine Verringerung der Festplattenlast, haben. Wahrscheinlich dürfte diese Kombination sogar das Gegenteil bewirken, weil sie den Kernel zwingt, die Page-Caches zugunsten der Ramdisk und des leeren Swap-Speichers zu verkleinern. Das führt dazu, dass Bibliotheken beim Starten von Programmen öfter erneut geladen werden müssen, und Lesezugriffe auf Dateien seltener oder gar nicht in den Page-Caches landen.

Das klingt einleuchtend. Wobei ich bei der Swappiness noch nicht überzeugt bin. Wenn der Kernel den RAM für die wichtigsten Dinge voll einspannt, wird alles weitere ja dort hin geschrieben. Ob ich also einige Dinge einmalig aus dem FS lesen und sie dann eventuell im SWAP landen und von da gelesen werden, oder ich sie nochmal vom SWAP lese, ist für die Aktivität der Festplatte doch kein Unterschied, oder?

Du scheinst dich sehr gut auszukennen. Ich habe diese Tipps aus dem Wiki (Tuning), vielleicht könntest du bei Gelegenheit mal einen Blick rein werfen und es gegebenenfalls anpassen. Es sollen ja nicht tausende Anwender Zeit und Arbeit investieren, um ihr System dann gar nicht wirklich verbessert zu haben.

Die /tmp/var habe ich wieder auf meine HD gelegt. Bei /tmp bin ich mir noch nicht sicher, ob bei ausreichendem RAM nicht doch ein Vorteil vorliegt. Auch beim Kernel werde ich - trotz deiner Ausführungen - noch weiter herumtesten. Ich habe Spaß daran und zudem lernt man ja oft auch was dazu.

Beim Wikiartikel zum Kernel ist mir aufgefallen, dass die Anleitung das Bauen mit root-Rechten im Verzeichnis /usr/src beschreibt. An anderer Stelle habe ich gelesen, dass man den Custom-Kernel besser in seinem /home/<user> Verzeichnis und keinesfalls als SuperUser-Rechten kompilieren sollte. Anscheinend kann es dabei noch zu Problemen kommen. Falls da jemand mehr weiß, wäre auch dort eine Änderung des Wikis zu empfehlen.

zarcaphii schrieb:

Ob ich also einige Dinge einmalig aus dem FS lesen und sie dann eventuell im SWAP landen und von da gelesen werden, oder ich sie nochmal vom SWAP lese, ist für die Aktivität der Festplatte doch kein Unterschied, oder?

Es geht hier um unterschiedliche Daten. Eine niedrige vm.swappiness Einstellung zwingt den Kernel dazu, den Cache erst zu verkleinern, bevor Anwendungen ausgelagert werden. Dadurch erzeugen Dateizugriffe mehr Festplattenlast, da die Wahrscheinlichkeit, dass eine Datei im Cache ist, geringer ist. Typischerweise finden in einem System aber sehr viele Dateizugriffe statt, vieles davon auch im Hintergrund. Dafür gibt es aber diverse Hintergrundprozesse, die längere Zeit schlafen. Folglich führt deine Einstellung dazu, dass der Kernel de facto zugunsten inaktiver Anwendungen mehr wiederholte Festplattenzugriffe durchführt, anstatt eine Anwendung einmalig auszulagern. Normalerweise ist das natürlich ziemlich egal, weil bei heutigen Speichergrößen nur ein Bruchteil durch Anwendungsspeicher belegt ist.

In Verbindung mit einer unter Umständen großen Ramdisk kann es aber negative Auswirkungen haben. Erzeugt ein Programm eine große temporäre Datei (z.B. ein ISO-Image zum Brennen einer CD), muss der Kernel die Caches verkleinern, selbst wenn auf deinem Desktop diverse Anwendungen gerade vor sich hin schlafen.

Anmerken möchte ich noch, dass meine Ansicht keinesfalls auf Erfahrung basiert, sondern allenfalls ein imho wahrscheinliches Szenario darstellt. Bevor du diese Einstellung dauerhaft übernimmst, solltest du imho neutral überprüfen, ob sich die Festplattenlast tatsächlich verringert.

Du scheinst dich sehr gut auszukennen. Ich habe diese Tipps aus dem Wiki (Tuning), vielleicht könntest du bei Gelegenheit mal einen Blick rein werfen und es gegebenenfalls anpassen. Es sollen ja nicht tausende Anwender Zeit und Arbeit investieren, um ihr System dann gar nicht wirklich verbessert zu haben.

Ich halte es für wenig sinnvoll, etwas zu ändern, ohne darüber zu diskutieren. Du könntest im Wiki-Forum einen Diskussionsthread über diesen Artikel starten, und hier verlinken. Dann würde ich meine Ansicht zu dieser Sache dort nochmal erläutern. Der Vorteil an dieser Vorgehensweise ist, dass andere (insbesondere der Autor der Seite) dazu Stellung nehmen kann.

Bei /tmp bin ich mir noch nicht sicher, ob bei ausreichendem RAM nicht doch ein Vorteil vorliegt.

Das kommt darauf an, welche Dateien auf deinem System dort landen. Bleibt /tmp klein, ist das durchaus sinnvoll.

Auch beim Kernel werde ich - trotz deiner Ausführungen - noch weiter herumtesten. Ich habe Spaß daran und zudem lernt man ja oft auch was dazu.

Selbstverständlich. Zum Lernen und Verstehen ist das eine feine Sache. Nur kann man von einem eigenen Kernel keine großen Leistungssteigerungen erwarten.

Lunar schrieb:

Selbstverständlich. Zum Lernen und Verstehen ist das eine feine Sache. Nur kann man von einem eigenen Kernel keine großen Leistungssteigerungen erwarten.

Es sei denn, man nutzt spezielle Kompileroptionen, aber auch da gilt aufpassen und testen, nicht alle Optionen vertragen sich mit dem Kernel.

stfischr schrieb:

Lunar schrieb:

Selbstverständlich. Zum Lernen und Verstehen ist das eine feine Sache. Nur kann man von einem eigenen Kernel keine großen Leistungssteigerungen erwarten.

Es sei denn, man nutzt spezielle Kompileroptionen, aber auch da gilt aufpassen und testen, nicht alle Optionen vertragen sich mit dem Kernel.

Selbst mit tollen "speziellen Kompileroptionen" hält sich der Nutzen in sehr engen Grenzen. Zwischen einem normalen 64-Bit-Ubuntu-Kernel und einem selbstkompilieren Gentoo-Kernel ist kein Unterschied spürbar.

Zum Lernen ist mein Vorhaben wirklich Klasse. Man sieht eine Konfiguration und fragt sich z.B., ob man SCSI überhaupt braucht, wenn man keinen SCSI-Festlatten benutzt. Zuerst natürlich mal gnadenlos abschalten. Dann liest man sich schlau und weiß danach, dass SATA, USB-Storage,... auf der SCSI-Übertragung aufsetzen und dass darum der 2 Stunden lang kompilierte Kernel nicht bootet ^.^

Ich habe mich nur gewundert, was mit den 'IBM Thinkpad Extras' passiert ist. Die gab es doch mal in .config, oder nicht? Ich habe so'n Teil (allerdings neuer, sprich Lenovo).

P.S.:Ich habe im der Diskussion zum Artikel Tuning (http://forum.ubuntuusers.de/topic/tuning-wiki-ueberarbeiten/) mal Lunar's Gedanken zitiert.