Schlagwort ‘Leistung‘

FreeBSD: Optimierung

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

, , , , , , , , , , , ,

RSS-Feed abonnieren