Dieser Beitrag wurde vor mehr als drei Monaten veröffentlicht. Bedenke bitte, dass die hier angebotene Information nicht mehr aktuell und gültig sein könnte. Informiere dich daher bitte auch an anderer Stelle über dieses Thema. Sollten sich neue Informationen ergeben haben, so kannst du mich auch gerne auf diese über einen Kommentar hinweisen. Vielen Dank!
1.) Kenne dein System (Hardware)
Am besten ist es den Flaschenhals an seinem System ausfindig zu machen, dafür sollte man wissen wie viel Arbeitsspeicher zur Verfügung steht, CPU Auslastung, Festplattengeschwindigkeit etc. aktuell verbraucht wird. Ggf. kann man auch mit neuer Hardware (z.B. > RAM) das System beschleunigen, dies muss natürlich bei jedem System einzeln geprüft werden.
1.1) Arbeitsspeicher
free -mt
total: kompletter physikalischer Speicher ( - ein wenig für den Kernel)
use: verwendeter Speicher
free: freier Speicher
buffers/cache: Speicher der wieder freigegeben werden kann, wenn dieser benötig wird. (Cache)
Somit sollte auch klar sein, dass es GUT ist, wenn der Arbeitsspeicher gut ausgenutzt wird, sollte jedoch "use" - "buffer/cache" zu klein werden oder bereits "Swap" (Auslagerungsspeicher -> meist Festplattenplatz) verbracht wird und somit das System wirklich ausbremst.
1.2) Festplatte
hdparm -t /dev/harddrive
Wenn es ewig dauert bis das System gebootet ist oder Programme starten, sollte man die Lesegeschwindigkeit seiner Festplatte einmal testen und ggf. eine neue Festplatte kaufen. Dabei sollte die Festplatte nicht unter ~50MB/s sein. Moderne SATA-Festplatten haben im Durchschnitt 100MB/s und bei SSD-Festplatten ist eine Datenraten bis zu ~500 MB/s möglich. (SATA-600).
Wenn du Engpässe beim abspielen von Videos oder beim Spielen feststellst, kannst du mit dem vorherigem Befehl feststellen, ob "Direct Rendering" aktiviert ist. Ggf. reicht es aus andere Treiber zu installieren, nach meiner Erfahrung sind die Proprietäten Treiber bei neuen Grafikkarten (ATI & NVIDIA) sehr gut. (http://suckup.de/blog/2010/02/09/lxde-compiz-emerald-awn-ubuntu-howto/) Wer eine alte Grafikkarte hat, kann auch diese 3D-Effekte (Compiz) ausschalten, ggf. andere Treiber installieren und schauen, ob der Desktop dadruch flüssiger läuft.
2.) Lightweight Software
Bevor man in neue Hardware investiert (oder sich diese zu Weihnachten schenken lässt) sollte man einmal "Lightweight Software" ausprobieren, diese bieten zwar ggf. weniger Funktionen, sind dafür aber schneller.
Als erstes sollte man sich ein wenig mit dem Filesystem beschäfitigen, da ganz nach verwenddung ggf. ein anderes Filesystem verwendet werden sollte.
Zusammenfassung:
XFS: ausgezeichnete Leistung bei großen Dateien, dafür langsamere Geschwindigkeit bei kleinen Dateien (z.B. für ISO's oder großen Downloads unter /home)
Reiserfs: ausgezeichnete Leistung bei kleinen Dateien (z.B. für viele kleine Dateien unter /var)
Ext3: durchschnittliche Leistung
Ext4: super Gesamtleistung (Leistungsprobleme bei sqlite und anderen Datenbanken)
JFS: gute Gesamtleistung (sehr geringe CPU-Last)
Btrfs: super Gesamtleistung (besser als ext4 ABER ggf. unstable)
Ein weitere Möglichkeit das Dateisystem zu optimieren, sind die "Mount Optionen", diese trägst du in der Datei "/etc/fstab" ein. So kann man z.B. durch "relatime" oder "noatime" verhindern, dass die Zugriffszeiten in der Inodetabelle gespeichert werden und so die Festplattenaktivität reduziert werden.
Sowohl bei Ext3 als auch bei Ext4 wird ein Journal geschrieben, dieses kann man mit der Option "data=writeback" einschränken und somit die Preformance steigern, kann jedoch zu Problemen führen, da die metadata nun "träge" gespeichert werden.
'Journal' - Langsamster und sicherster Modus. Nicht nur die Metadaten sondern auch die Nutzdaten werden zunächst in das Journal, und dann erst auf die Festplatte geschrieben.
'Ordered' - Guter Kompromiss aus Sicherheit und Geschwindigkeit (Standard). Die Nutzdaten werden auf die Festplatte geschrieben sobald die Metadaten im Journal abgelegt wurden.
'Writeback' - Schnell, dafür relativ unsicher. Die Nutzdaten werden sofort auf die Festplatte geschrieben ohne das gewartet wird bis die Metadaten im Journal abgelegt wurden.
tune2fs -o journal_data_writeback /dev/partition
mit dem vorherigem Befehl schreibt man das vorhandene Journal um...
"noatime" sagt aus, dass nicht gespeichert wird, wann die Datei angesehen wurde. (man liest eine Datei und gleichzeitig wird auf die Dateien geschrieben) Auch "barrier=0" trägt dazu bei, dass deine Daten unsicherer sind, die Option steigert jedoch die Performance. (so soll die Option einen sehr positiven Einfluss auf die Schreib-Performance von MySQL haben) Die Option "nobh" versucht "associating buffer heads" zu vermeiden und bringt eine kleine Performace verbesserung. Als nächstes kommt die Option "commit=100", diese Option sagt aus, dass die Daten nur alle 100 Sekunden auf die Festplatte geschrieben werden, dafür verliet man ggf. auch 100 Sekunden bei einem Ausfall (default 5). "nouser_xattr" schaltet einige weitere Optionen vom Dateisystem aus und bringt noch einmal einen kleinen Performanceschub.
... und die "Mount Option" -> "logbufs=8" in der fstab einfügen. Zudem kann man das gemountete XFS-Filesysteme per "filesystem reorganizer for XFS" Optimieren.
Die Option "data=writeback" beschleunigt das Dateisystem, kann jedoch zu Datenverlust beim Stromausfall führen. Auch "notail" beschleunigt Reiserfs bewirkt jedoch, dass zirka 5% mehr an Festplattenplatz benötigt wird. Zudem kann man mit dem nächsten Befehl bereits beim erstellen das Dateisystems dieses beschleunigen, indem man das Journal auf eine zweite Partition auslagert.
Dieses neue Dateisystem bietet "online Defragmentation", "Optimierungen für SSDs", "Snapshots" und viele weitere Sinnvolle Funktionen, wird jedoch momentan noch aktiv entwickelt.
(Im Arch-Linux Wiki habe ich auch noch von der Möglichkeit gelesen "/usr" komplett zu komprimieren (aufs2 + squashfs-tools) da moderne CPUs schneller die Dateien entpacken können als das größere Daten von der Festplatte geladen werden können, leider habe ich diesbezüglich keine Infos zu Ubuntu gefunden.)
4.) CPU
Hier kann man in erster Lienie Overclocking betreiben und somit einiges an Geschwindigkeit herausholen, so habe ich z.B. aus einem "AMD Athlon II X3" einen "AMD Athlon II X4" gemacht. (PS: wer Fragen zur Hardware hat, sollte sich einmal das Computerbase-Forum anschauen, habe dort auch meinen neuen PC gemeinsam mit anderen Mitgliedern zusammengestellt -> "http://www.computerbase.de/forum/showthread.php?p=8532713" + Vorlagen für verschiedene Preisklassen http://www.computerbase.de/forum/showthread.php?p=3395405)
Wenn man auf der Software-Seite seine CPU besser nutzen möchte kann man einen optimierten Kernel bauen oder zumindest bei Arch-Linux sein System mit neuen "CFLAGS & CXXFLAGS" neu-kompilieren lassen. (https://wiki.archlinux.org/index.php/Pacbuilder) Falls jemand ein ähliches Programm für Ubuntu kennt, würde ich dies gerne erfahren.
"swappiness" ist eine Einstellung, welche dem Kernel mitteilt ob der RAM oder der SWAP bevorzugt werden soll. Der Wert der Variablen kann zwischen 0 und 100 liegen. Der Wert 0 bedeutet, dass der Kernel den Auslagerungsspeicher auf der Festplatte (swap) nur dann nutzt, wenn es nicht anders geht. Der Wert 100 bedeutet das genaue Gegenteil. Es wird so früh wie möglich ein unbenutzter Speicherbereich in den Swapspeicher geschoben.
vim /etc/sysctl.conf
vm.swappiness=20
vm.vfs_cache_pressure=50
5.2) Compcache
Compcache, auch als "ramzswap kernel module" bezeichnet erstellt Swap im Arbeitsspeicher und komprimiert diesen. So dass zwar die CPU wieder mehr zu tun hat, wir jedoch mehr Auslagern können, ausserdem hat dies den Vorteil, dass die Lese-/Schreizugriffe auf der Festplatte weiter reduziert werden.
Einen ählichen Ansatz, wie "Compcache" verfolgt auch "tmpfs" hier werden die Daten jedoch einfach in den Arbeitsspeicher geschrieben, ohne diese zu komprmieren. Wenn man jedoch genügent Speicher übrig hat, kann man so z.B. die "/tmp"-Daten in den Speicher auslagern.
ureadahead ist standardmäßig bereis bei Ubuntu installiert und lädt Programme bereits beim Bootvorgang in den RAM, falls man z.B. preload (apt-get install preload) einsetzten will, sollte man ureadahead deaktivieren, da es die selbe Aufgabe übernimmt. "preload" hat den Vorteil, dass es im Betrieb protokolliert welche Programme wirklich verwendet werden und nur diese bereits beim Boot in den RAM lädt, daher startet das System schneller, die Programm werden jedoch nicht schneller gestartet als mit ureadahead. (persönliche Meinung - nicht auf die Millisekunde gemessen) außerdem verursacht das Programm "preload" immer CPU-Last und verbraucht somit mehr Strom als wie ohne. Um den Boot-Vorgang näher zu analysieren soll man sich einmal "bootchart" (http://wiki.ubuntuusers.de/bootchart) anschauen.
8.) prelink
Wenn man den Start von Programmen beschleunigen will, kann man "prelink" (apt-get install prelink) ausprobieren, besonders bei KDE bringt dies einiges, da somit bei "dynamic linking" Programmen (Programm die nicht gelinkt sind, um z.B. Speicherplatz zu sparen) die Libraries nicht jedesmal bei geladen werden müssen. Prelink nutzt dies insofern aus, als dass es das Linken im Voraus ausführt und in der Programmdatei abspeichert. Somit kann man (fast) jedes Programm beschleunigen.
Nicht verwendete Sprachdateien zu entfernen erscheint zwar auf den ersten Blick nicht wirklich als Optimierung, jedoch hat sich in der Praxis gezeigt, dass einige Programm diese Sprachdateien z.B. beim Start in den Speicher laden, daher kann man so nicht nur Festplattenplatz, sondern ggf. auch Arbeitsspeicher einsparen und Programme schneller starten.
Interessanter Eintrag.
Jetzt weiß ich schonmal, dass mein Weihnachtsgeld für ne schnellere Festplatte draufgeht. Die anderen Dinge muss ich auch ausprobieren.
Am Interessantesten dürfte das Kerneltuning sein. Dummerweise lassen sich die beiden Patches nicht kombinieren, da bei Einsatz des BFS das sogenannte "Automatic process group scheduling" nicht funktioniert. Gerade mit Letzterem habe ich gute Erfahrungen gemacht. Was den besseren Schub bringt, wäre interessant zu wissen. Auch würde ich mal echt gern einen "Minimalkernel" bauen, d.h. einen Kernel der nur die Treiber enthält die für mein Centrinosystem unbedingt nötig sind. Leider bricht der Buildprozess immer ab wenn ich größere Treiberzweige "ausbaue", die Fehlerhinweise sind unzureichend um das zu lösen. Das wärs noch: eine Möglichkeit in Kernelcheck ganze Gerätegruppen abzuwählen, inkl. einer Art Abhängigkeitsprüfung die Konflikte automatisch auflöst. Schade auch...
War doch nichts zu kompilieren.
Nach dem COMPCACHE_SIZE="30%" in /etc/initramfs-tools/initramfs.conf eingestellt wurde, war /dev/ramzswap0 da, konnte es nur nicht einbinden.
Abhilfe hat mir
/usr/lib/initramfs-tools/bin/rzscontrol /dev/ramzswap0 --init
und dann erst
swapon -p 100 /dev/ramzswap0
gebracht.
Steht jetzt im rc.local und ist auch schon im conky zwecks Beobachtung angezeigt.
Danke für die Infos ... werde so schnell wie möglich diesen Blog-Post updaten und ein kleines HowTo für Compcache einfügen.
---
"COMPCACHE-HowTo" -> and if anyone has other suggestions, I would like to test it and update this post after that / und wenn jemand weitere Vorschläge hat, werde ich diese gerne testen und mit aufnehmen
Hallo,
ich benutze mittlerweile seit einer Weile den Zen-Kernel unter Debian. Da sind der BFS und diverse andere Patches schon mit drin. Die Seite hierzu: http://zen-kernel.org
"zen-kernel", "COMPCACHE-HowTo" -> and if anyone has other suggestions, I would like to test it and update this post after that / und wenn jemand weitere Vorschläge hat, werde ich diese gerne testen und mit aufnehmen
Ich habe gerade auf der Zen-Seite gesehen, dass der Liquorix-Kernel quasi ein fertiges deb-Paket extra für Debian darstellt: "Liquorix provides debian builds of the zen kernel for debian testing, sid, or any testing/sid based distributions."
Den Vorteil bei Zen sehe ich darin, dass es ein Community-Projekt ist. Hier kann man sich einige wesentliche Merkmale des Patches oder auch git anschauen: http://zen-kernel.org/included-code
Very nice info Voku, even i have to use Google translate to understand your article
For the DNS part, why you don't use OpenDns instead?
It is fast and reliable.
"zen-kernel", "openDNS", "COMPCACHE-HowTo" -> and if anyone has other suggestions, I would like to test it and update this post after that / und wenn jemand weitere Vorschläge hat, werde ich diese gerne testen und mit aufnehmen
"zen-kernel", "openDNS", "COMPCACHE-HowTo", "Raid", "TCP-Tuning" -> and if anyone has other suggestions, I would like to test it and update this post after that / und wenn jemand weitere Vorschläge hat, werde ich diese gerne testen und mit aufnehmen
... und wünsche allen ein schönes Weihnachtsfest