noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28947
Wohnort: WW
|
Hallo, @kaputtnik: Yup, startet dazu am besten eine Supportthread... und eine letzte Anmerkung hier dazu: bei mir hat das in einer alten Ubuntu Version irgendwie an der Netzwerkerkennung gehangen, war aber irgendwann weg. Bitte der Vollständigkeit halber den Link auf den Supportthread hier posten. Gruß noisefloor
|
thom_raindog
Anmeldungsdatum: 20. Mai 2005
Beiträge: 2848
|
mniess hat geschrieben:
Und bei Multiprozessorsystemen und Pentiums mit Hyperthreading bringt es 5-10sek schnellere startzeit, wenn man upstart erlaubt startprozesse parallel auszufuehren (das sollte ja eigentlich das killerfeature von upstart sein.. ist aber per default deaktiviert)..
Hab ich das in dem Artikel nur nicht gefunden, oder ist es nicht drin?
|
Onli
Ehemalige
Anmeldungsdatum: 1. August 2005
Beiträge: 6941
|
Nun, es hat ja keiner was dazu geschrieben. Upstart sollte auch von Anfang an Prozesse wenn möglich parallel ausführen. Ich fand auch in der Dokumentation kein Hinweis auf eine solche zusätzliche Option. Wenn es sowas doch gibt, wäre es auch in Upstart besser aufgehoben, in Tuning könnte man es verlinken. Gruß
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28947
Wohnort: WW
|
Hallo, Upstart _soll_ irgendwann sowas können, befindet sich aber (immer noch) in den Anfängen. AFAIK werden größtenteils immernoch die normalen init-Skripte seriell durchlaufen... Gruß noisefloor
|
burli
Anmeldungsdatum: 27. April 2007
Beiträge: 9000
Wohnort: Petersberg
|
Hallo, ich habe den Artikel Tuning um einen weiteren Beitrag bereichert. Bitte schaut mal drüber ob das alles soweit in Ordnung ist. http://wiki.ubuntuusers.de/Tuning#Desktop-Performance
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28947
Wohnort: WW
|
Hallo, inhaltlich denke ich ok, habe es noch ein wenig hübscher formatiert. Rein Interesse halber: gibt es dazu Messwerte o.ä. oder ist das alles rein "gefühlt"? Gruß, noisefloor
|
burli
Anmeldungsdatum: 27. April 2007
Beiträge: 9000
Wohnort: Petersberg
|
noisefloor schrieb: inhaltlich denke ich ok, habe es noch ein wenig hübscher formatiert.
Ok, danke
Rein Interesse halber: gibt es dazu Messwerte o.ä. oder ist das alles rein "gefühlt"?
Nein, hab ich natürlich gemessen. Hab am Ende des Artikels auch einen Link zu meine Blog in dem ich ein paar Werte aufgelistet hab. Hab auch vorher schon hier im Forum dazu was geschrieben.
|
zarcaphii
Anmeldungsdatum: 17. Mai 2008
Beiträge: 82
|
In einem Thread (http://forum.ubuntuusers.de/topic/systemoptimierung-mit-custom-kernel-tmpfs-..-/) findet eine Diskussion über bestimmte Tunings aus diesem Artikel statt. Folgende Statements von Lunar sind dabei imo interessant: 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.
/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.
|
Onli
Ehemalige
Anmeldungsdatum: 1. August 2005
Beiträge: 6941
|
zarcaphii schrieb: Folgende Statements von Lunar sind dabei imo interessant: 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.
Richtig, und falsch. Ja, bei einem modernene System wird man einen selbstgebauten Kernel kaum spüren. Bei einem 300 MHZ-System mit wenig Ram macht er den Unterschied zwischen nutzbar und unnutzbar, zwischen einer Minute und drei Minute Bootzeit. Zu den Prozessen: Inzwischen (oder im Zweifel: Nachdem sie irgendwann installiert wurden) startet Ubuntu natürlich Prozesse, die nicht für jeden Nutzertyp notwendig sind. Und auch kernelbezogene Prozesse kann man deaktiveren, den Logger z.B. - nur, dass das nicht unbedingt empfehlenswert ist. Nur muss man dafür eigentlich nicht den Kernel neu kompilieren. /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.
Dann sollte man das im Artikel ändern. 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.
Nicht auszuschließen. vm.swappiness=0 bewirkt, dass so spät wie möglich Dateien vom Ram in den Swap auf der Festplatte geschoben werden, und bewirkt von daher eine niedrigere Festplattenlast. Vorraussetzung ist hierbei natürlich, dass der Ram groß genug ist, sodass die von Lunar beschrieben Situation eben nicht eintritt.
Ich bin mir allerdings nicht sicher, ob eine oder von welcher der Ramdisk-Methoden Ram wirklich im Vorraus reserviert wird. Wenn das nicht getan wird, wovon ich eigentlich ausgehe, dann gilt das ja nur wenn /tmp wirklich stark belegt wurde (oder auch: der Ram so klein ist, dass durch die stärkere /tmp Belegung im Ram die Miss-Rate der häufig genutzten Programme (wesentlich) steigt).
|
zarcaphii
Anmeldungsdatum: 17. Mai 2008
Beiträge: 82
|
Also jetzt, nach 30 Stunden Uptime und mit Alltagsmultitasking (Browser, Musik, 1-2 Terminals, einige kleine Einstellgungen und andere Programme zwischendurch) hat /tmp bei mir eine Größe von 115,4 KB. Man könnte meiner Meinung nach also sagen, dass die Verlegung von /tmp in den RAM dann sinnvoll ist, wenn man selten Programme nutzt, die mit größeren Dateien in /tmp arbeiten (Jeden Tag 10 CDs kopieren,... was noch?). Solange die RAMDISK klein gehalten wird, bleibt ja genug Cache um RAM-Misses nicht signifikant steigen zu lassen.
|
Lunar
Anmeldungsdatum: 17. März 2006
Beiträge: 5792
|
Onli schrieb: zarcaphii schrieb: Folgende Statements von Lunar sind dabei imo interessant: 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.
[...] Bei einem 300 MHZ-System mit wenig Ram macht er den Unterschied zwischen nutzbar und unnutzbar, zwischen einer Minute und drei Minute Bootzeit.
Abgesehen von der Initrd hat der Kernel nichts mit dem Boot-Prozess zu tun. Der einzige Vorteil, den ein eigener Kernel beim Booten bringt, ist das statische Kompilieren der benötigten Module, was unter Umständen den Verzicht auf die initrd ermöglicht. Ansonsten ist das Booten aber Sache von init, der Kernel hat da nicht mehr zu tun als während des normalen Betriebs. Zudem dürfte der Bootvorgang durch höhere Ausführungsgeschwindigkeiten wenig bis gar nicht beschleunigt werden, da das Gros der Aktivität beim Booten auf die Festplatte entfällt, die bei einem derart alten Rechner auch entsprechend langsam sein dürfte. Zudem verringert sich der Speicherverbrauch durch einen selbst kompilierten Kernel nicht, da auch bei einem System mit vorkompiliertem Kernel nur die benötigten Module laufen. Zwar kann man den Speicherverbrauch durch spezielle Konfigurationsoptionen senken (z.B. in der der gcc -Os nutzt), das geht aber zu Lasten der Ausführungsgeschwindigkeit und birgt die Gefahr von Inkompatibilitäten.
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.
Nicht auszuschließen. vm.swappiness=0 bewirkt, dass so spät wie möglich Dateien vom Ram in den Swap auf der Festplatte geschoben werden, und bewirkt von daher eine niedrigere Festplattenlast. Vorraussetzung ist hierbei natürlich, dass der Ram groß genug ist, sodass die von Lunar beschrieben Situation eben nicht eintritt.
Ich bin mir allerdings nicht sicher, ob eine oder von welcher der Ramdisk-Methoden Ram wirklich im Vorraus reserviert wird.
tmpfs ist eine dynamisch wachsende Ramdisk, so dass eine leere Ramdisk keinen Speicher benötigt. Daher ist es normalerweise auch nicht schlimm, wenn /tmp im Ram liegt. Allerdings gibt es ja keine Größenbeschränkung für temporäre Dateien, daher ist durchaus eine Situation vorstellbar, in der beispielsweise eine Brennanwendung ala K3B ein 700 MiB großes Disk-Abbild in /tmp erzeugt ...
Auf diesen Umstand sollte zumindest hingewiesen werden.
|
zarcaphii
Anmeldungsdatum: 17. Mai 2008
Beiträge: 82
|
Noch was:
Um eine SSD zu schonen sollte sich die RAM-Disk Methode + vm.swappiness=0 aber schon lohnen, da ja die Schreibarbeit weiter in Richtung RAM verlagert wird. Es müssen zwar eventuell einige Dinge öfter von der Festplatte gelesen werden, aber das schädigt die Speicherzellen nicht und dauert ja bei einer SSD nicht so lange wie bei normalen Platten.
|
Onli
Ehemalige
Anmeldungsdatum: 1. August 2005
Beiträge: 6941
|
Auf diesen Umstand sollte zumindest hingewiesen werden.
Ja, klar, da wollt ich auch gar nicht wiedersprechen ☺ Der einzige Vorteil, den ein eigener Kernel beim Booten bringt, ist das statische Kompilieren der benötigten Module, was unter Umständen den Verzicht auf die initrd ermöglicht.
Selbst wenn man dann nicht auf die initrd verzichtet gewinnt man dadurch Zeit. Beim Treiberladen nämlich. Da macht es halt schon einen Unterschied, ob das meiste fest einkompiliert ist und nicht da was nicht nötig, oder ob fast alles in Modulform betrachtet und teils geladen werden muss. Insbesondere bei der alten Platte bewirkt das schon viel. Wie gesagt, das brachte fast zwei Minuten. Zudem verringert sich der Speicherverbrauch durch einen selbst kompilierten Kernel nicht, da auch bei einem System mit vorkompiliertem Kernel nur die benötigten Module laufen.
Ich habe trotzdem die Erfahrung gemacht, dass mit dem selbstkompilierten Kernel ganz normale Desktoparbeit angenehmer war, da weniger schnell das System anfing zu ruckeln. Natürlich ist das möglicherweise Einbildung gewesen, vielleicht hat aber z.B. der Wechsel zur alten IDE-Anbindung den Unterschied bewirkt (evtl. in Kombination mit dadurch möglich gewordenen hdparm-Optionen) - wenn ich nochmal die Gelegenheit bekommen sollte mess ich mal nach. Mir hat der Bootzeitgewinn und das angepasste acpi damals als Argument genügt. @zarcaphii: Wenn bei einem Miss von der Platte gelesen werden sollte wird das dann ja auch gecached, wodurch indirekt wieder was in den Festplattenswap geschoben wird. Trotzdem: Wenn /tmp nicht groß befüllt wird hast du schon recht damit (und nach deiner Beobachtung ist dem ja so bisher gewesen). Es fehlt an der Stelle einfach der Hinweis, dass /tmp auch recht groß werden kann, Lunars Beispiel war k3b.
Gruß
|
zarcaphii
Anmeldungsdatum: 17. Mai 2008
Beiträge: 82
|
Wenn bei einem Miss von der Platte gelesen werden sollte wird das dann ja auch gecached, wodurch indirekt wieder was in den Festplattenswap geschoben wird.
Wenn die vm.swappiness=0 gesetzt ist, wird doch zuerst im RAM Platz gemacht, indem gecachte Daten an anderer Stelle entfernt werden. Geswappt wird erst, wenns unbedingt sein muss. Und nochmal eine Frage: Wenn der Kernel genug RAM zur Verfügung hat, dann landen Dateien aus /tmp doch mit großer Wahrscheinlichkeit sowieso im Cache, oder nicht?
|
Lunar
Anmeldungsdatum: 17. März 2006
Beiträge: 5792
|
zarcaphii schrieb: Und nochmal eine Frage: Wenn der Kernel genug RAM zur Verfügung hat, dann landen Dateien aus /tmp doch mit großer Wahrscheinlichkeit sowieso im Cache, oder nicht?
Ja. @Onli Ok, ich hätte nicht geglaubt, dass das bei einem so alten System tatsächlich so große Vorteile bringt. Ich habe damit keine Erfahrungen, das war vor meiner Linux-Zeit ... 😉
|