Nicht Rennstreifen sind das Ziel oder Aussagen a la «30% schneller», sondern schlicht Verbesserungen des Gesamtverhaltens. Natürlich ist ein derartiges Optimieren der Konfiguration vom jeweiligen Kontext abhängig, was den einen Nutzen bringt, verpufft u.U. bei anderen oder wirkt sich gar kontraproduktiv aus.
FreeBSD bietet grundsätzlich keine Optimierung, wie sie bei vielen Linux-Distributionen usus ist. Das Betriebssystem bildet die Basis und liefert vielerlei Werkzeuge, es geht dem Anwender aber in der Regel aus dem Weg, hält ihn nicht an der Hand. Der eine mag dies als Nachteil sehen, der andere als Vorteil. Your mileage may vary.
Beginnen wir mit dem Datenträger. Es existieren eine Menge Möglichkeiten diesem auf die Sprünge zu helfen. Die simpelste Variante wäre der Kauf einer SSD, die zweite Möglichkeit wäre der Einsatz eines anderen Filesystems wie ZFS. Bringt viele Vorteile mit sich, aber auch einen Sack voller Nachteile, insbesondere in puncto Ressourcenverbrauch. Dabei geht es aber auch mit UFS und ohne den Kauf neuer Hardware.
echo 'ahci_load="YES"' >> /boot/loader.conf
echo 'geom_sched_load="YES"' >> /boot/loader.conf
echo 'gsched_rr_load="YES"' >> /boot/loader.conf
echo 'kern.maxfiles=16384' >> /boot/loader.conf
echo 'kern.maxfilesperproc=8192' >> /boot/loader.conf
echo 'vfs.ufs.dirhash_maxmem=67108864' >> /etc/sysctl.conf
echo 'vfs.read_max=32' >> /etc/sysctl.conf
Ahci lädt den neuen Treiber für SATA-Geräte, man gewinnt etwas an Geschwindigkeit, eine bessere Unterstützung diverser Fähigkeiten der einzelnen Geräte und die Gerätenamen ändern sich. Bei mir änderte sich beispielsweise die Bezeichnung der Festplatte von ad4 zu ada0, also Obacht! Ansonsten wird ein Disk-IO-Scheduler geladen, sowie ein paar allzu konservativ gehaltene System-Variablen angepaßt. Bei letzteren tritt natürlich einzig ein Effekt ein, wenn man überhaupt kritische Grenzen auf dem eigenen System erreicht. Ist dies nicht der Fall, tritt auch keine wundersame Beschleunigung in Erscheinung. Kurzum, wer ein wenig Mail, WWW & Co macht, der wird mit diesen Einstellungen nichts gewinnen. Nutzer von KDE, Zeitgenossen die viel mit Dateien arbeiten oder diese auch oft parallel schreiben, werden hingegen teils einen spürbaren Unterschied registrieren.
echo 'geom sched insert -a rr ada0' >> /etc/rc.local
Der zuvor geladene Disk-IO-Scheduler muß noch installiert werden für den jeweiligen Datenträger, mehr Konfiguration ist nicht notwendig.
echo 'tmpfs_load="YES"' >> /boot/loader.conf
echo 'tmpfs /tmp tmpfs rw,mode=1777 2 0' >> /etc/fstab
echo 'tmpfs /var/tmp tmpfs rw 2 0' >> /etc/fstab
Die Wirksamkeit von Tmpfs entfaltet sich ebenso nur auf Systemen, die auch ausgiebig Gebrauch von temporären Dateien machen, z.B. wenn ports kompiliert werden. Nicht vergessen sollte man, den alten Eintrag für tmp in /etc/fstab auszukommentieren. Tmpfs gilt noch als experimentell, tritt eine Panic auf, so ist diese jedoch in der Regel zu geringem Hauptspeicher geschuldet. Ich setzte tmpfs seit mehr als einem Jahr regelmäßig ohne Probleme ein.
Mehr Informationen erhält man in tuning, sollte sich aber darüber im klaren sein, was man da en Detail tut. Viele Systemparameter sollten nur in grenzwertigen Situationen z.B. auf einem stark frequentierten Server anpaßt werden. Obige Optimierungen können helfen, schaden aber auch nichts, außer, daß beispielsweise ein wenig mehr Speicher abgezweigt wird in MB-Dimensionen.
Bild: der Bulo
Alternative, Anleitung, Betriebssystem, BSD, FOSS, FreeBSD, Leistung, Open Source, Optimierung, Performance, Tipps, Tuning, Unix
Lange hatte ich hier nichts mehr zu FreeBSD geschrieben, um so erfreulicher nun, die Veröffentlichung des ersten Release Kandidaten bekanntgeben zu können. Klar, so ganz offiziell ist der noch nicht, aber just auf dem Server eingeschlagen und bereit ausgiebig getestet zu werden.
