Connect with us

Wie man

So optimieren Sie Ihre SSD in Ubuntu für eine bessere Leistung

So optimieren Sie Ihre SSD in Ubuntu für eine bessere Leistung

Es gibt viele Tipps zum Optimieren Ihrer SSD unter Linux und viele anekdotische Berichte darüber, was funktioniert und was nicht. Wir haben unsere eigenen Benchmarks mit einigen spezifischen Optimierungen durchgeführt, um Ihnen den wirklichen Unterschied zu zeigen.

Benchmarks

Um unsere Festplatte zu vergleichen, haben wir die Phoronix Testsuite. Es ist kostenlos und verfügt über ein Repository für Ubuntu, sodass Sie nicht von Grund auf neu kompilieren müssen, um schnelle Tests durchzuführen. Wir haben unser System direkt nach einer Neuinstallation von Ubuntu Natty 64-bit mit den Standardparametern für das ext4-Dateisystem getestet.

Unsere Systemspezifikationen waren wie folgt:

  • AMD Phenom II Quad-Core @ 3,2 GHz
  • MSI 760GM E51-Mainboard
  • 3,5 GB RAM
  • AMD Radeon 3000 integriert mit 512 MB RAM
  • Ubuntu Natty

Und natürlich war die SSD, auf der wir getestet haben, ein 64-GB-OCZ-Onyx-Laufwerk ($117 auf Amazon.com zum Zeitpunkt des Schreibens).

Prominente Optimierungen

Es gibt einige Änderungen, die die Leute beim Upgrade auf eine SSD empfehlen. Nachdem wir einige der älteren Sachen herausgefiltert hatten, haben wir eine kurze Liste von Optimierungen erstellt, die Linux-Distributionen nicht als Standard für SSDs enthalten. Drei davon beinhalten die Bearbeitung Ihrer fstab-Datei, also sichern Sie diese, bevor Sie mit dem folgenden Befehl fortfahren:

sudo cp /etc/fstab /etc/fstab.bak

Wenn etwas schief geht, können Sie die neue fstab-Datei jederzeit löschen und durch eine Kopie Ihres Backups ersetzen. Wenn Sie nicht wissen, was das ist, oder die Funktionsweise auffrischen möchten, werfen Sie einen Blick auf HTG Explains: Was ist die Linux-fstab und wie funktioniert sie?

Verzicht auf Zugriffszeiten

Sie können dazu beitragen, die Lebensdauer Ihrer SSD zu verlängern, indem Sie reduzieren, wie viel das Betriebssystem auf die Festplatte schreibt. Wenn Sie wissen möchten, wann auf jede Datei oder jedes Verzeichnis zuletzt zugegriffen wurde, können Sie diese beiden Optionen zu Ihrer /etc/fstab-Datei hinzufügen:

noatime, nodiratime

Fügen Sie sie zusammen mit den anderen Optionen hinzu und stellen Sie sicher, dass sie alle durch Kommas und keine Leerzeichen getrennt sind.

Aktivieren von TRIM

Sie können TRIM aktivieren, um die Festplattenleistung langfristig zu verwalten. Fügen Sie Ihrer fstab-Datei die folgende Option hinzu:

verwerfen

Dies funktioniert gut für ext4-Dateisysteme, sogar auf Standardfestplatten. Sie müssen eine Kernel-Version von mindestens 2.6.33 oder höher haben; Sie sind abgesichert, wenn Sie Maverick oder Natty verwenden oder Backports auf Lucid aktiviert haben. Dies verbessert zwar nicht speziell das anfängliche Benchmarking, sollte jedoch die Leistung des Systems auf lange Sicht verbessern, und so wurde es in unsere Liste aufgenommen.

Tmpfs

Der Systemcache wird in /tmp gespeichert. Wir können fstab anweisen, dies als temporäres Dateisystem im RAM zu mounten, damit Ihr System die Festplatte weniger berührt. Fügen Sie am Ende Ihrer /etc/fstab-Datei in einer neuen Zeile die folgende Zeile hinzu:

tmpfs /tmp tmpfs Standardwerte,noatime,mode=1777 0 0

Speichern Sie Ihre fstab-Datei, um diese Änderungen zu übernehmen.

E/A-Scheduler wechseln

Ihr System schreibt nicht alle Änderungen sofort auf die Festplatte und mehrere Anfragen werden in die Warteschlange gestellt. Der Standard-Eingabe-Ausgabe-Scheduler – cfq – handhabt dies in Ordnung, aber wir können dies in einen für unsere Hardware besser funktionierenden ändern.

Listen Sie zunächst mit dem folgenden Befehl auf, welche Optionen Ihnen zur Verfügung stehen, und ersetzen Sie dabei „X“ durch den Buchstaben Ihres Root-Laufwerks:

cat /sys/block/sdX/queue/scheduler

Meine Installation ist auf sda. Sie sollten ein paar verschiedene Optionen sehen.

Wenn Sie eine Frist haben, sollten Sie diese verwenden, da Sie später eine zusätzliche Optimierung erhalten. Wenn nicht, sollten Sie noop ohne Probleme verwenden können. Wir müssen dem Betriebssystem mitteilen, dass es diese Optionen nach jedem Booten verwenden soll, also müssen wir die Datei rc.local bearbeiten.

Wir verwenden nano, da wir mit der Befehlszeile vertraut sind, aber Sie können jeden anderen Texteditor verwenden, den Sie mögen (gedit, vim usw.).

sudo nano /etc/rc.local

Fügen Sie oberhalb der Zeile «exit 0» diese beiden Zeilen hinzu, wenn Sie die Frist verwenden:

Echo-Deadline > /sys/block/sdX/queue/scheduler

echo 1 > /sys/block/sdX/queue/iosched/fifo_batch

Wenn Sie noop verwenden, fügen Sie diese Zeile hinzu:

echo noop > /sys/block/sdX/queue/scheduler

Ersetzen Sie erneut „X“ durch den entsprechenden Laufwerksbuchstaben für Ihre Installation. Schauen Sie sich alles an, um sicherzustellen, dass es gut aussieht.

Drücken Sie dann STRG+O zum Speichern und dann STRG+X zum Beenden.

Neustart

Damit all diese Änderungen wirksam werden, müssen Sie neu starten. Danach sollten Sie fertig sein. Wenn etwas schief geht und Sie nicht booten können, können Sie jeden der obigen Schritte systematisch rückgängig machen, bis Sie wieder booten können. Sie können sogar eine LiveCD oder LiveUSB zur Wiederherstellung verwenden, wenn Sie möchten.

Ihre fstab-Änderungen bleiben während der gesamten Lebensdauer Ihrer Installation erhalten, sogar trotz Upgrades, aber Ihre rc.local-Änderungen müssen nach jedem Upgrade (zwischen den Versionen) neu eingeführt werden.

Benchmarking-Ergebnisse

Um die Benchmarks durchzuführen, haben wir die Disk-Suite von Tests durchgeführt. Das obere Image jedes Tests ist vor dem Optimieren der ext4-Konfiguration und das untere Image ist nach den Optimierungen und einem Neustart. Sie sehen eine kurze Erläuterung der Messergebnisse sowie eine Interpretation der Ergebnisse.

Operationen mit großen Dateien

Dieser Test komprimiert eine 2-GB-Datei mit zufälligen Daten und schreibt sie auf die Festplatte. Die SSD-Optimierungen zeigen hier eine Verbesserung von etwa 40%.

IOzone simuliert die Dateisystemleistung, in diesem Fall durch das Schreiben einer 8-GB-Datei. Erneut eine Steigerung von fast 50 %.

Hier wird eine 8GB Datei gelesen. Die Ergebnisse sind fast die gleichen wie ohne Anpassung von ext4.

AIO-Stress testet asynchron Eingabe und Ausgabe mit einer 2 GB Testdatei und einer Datensatzgröße von 64 KB. Hier gibt es eine Leistungssteigerung von fast 200% im Vergleich zu Vanilla ext4!

Kleine Dateioperationen

Eine SQLite-Datenbank wird erstellt und PTS fügt ihr 12.500 Datensätze hinzu. Die SSD-Optimierungen hier haben die Leistung tatsächlich um etwa 10 % verlangsamt.

Der Apache Benchmark testet zufällige Lesevorgänge kleiner Dateien. Nach der Optimierung unserer SSD gab es einen Leistungsgewinn von etwa 25 %.

PostMark simuliert 25.000 Dateitransaktionen, 500 gleichzeitig gleichzeitig, mit Dateigrößen zwischen 5 und 512 KB. Dies simuliert Web- und Mailserver ziemlich gut und wir sehen nach der Optimierung eine Leistungssteigerung von 16%.

FS-Mark betrachtet 1000 Dateien mit einer Gesamtgröße von 1 MB und misst, wie viele in einer vorher festgelegten Zeit vollständig geschrieben und gelesen werden können. Unsere Optimierungen sehen mit kleineren Dateigrößen erneut eine Zunahme. Ungefähr 45% Steigerung mit ext4-Anpassungen.

Dateisystemzugriff

Die Dbench-Benchmarks testen Dateisystemaufrufe von Clients, ähnlich wie bei Samba. Hier wird die Leistung von Vanilla ext4 um 75 % reduziert, ein großer Rückschlag bei den von uns vorgenommenen Änderungen.

Sie können sehen, dass mit steigender Client-Zahl die Performance-Diskrepanz zunimmt.

Mit 48 Clients hat sich die Lücke zwischen den beiden etwas geschlossen, aber es gibt immer noch einen sehr offensichtlichen Leistungsverlust durch unsere Optimierungen.

Bei 128 Clients ist die Performance fast gleich. Sie können davon ausgehen, dass unsere Tweaks bei dieser Art von Betrieb möglicherweise nicht ideal für den Heimgebrauch sind, aber eine vergleichbare Leistung bieten, wenn die Anzahl der Clients stark erhöht wird.

Dieser Test hängt von der AIO-Zugriffsbibliothek des Kernels ab. Wir haben hier eine Verbesserung von 20 %.

Hier haben wir einen Multithread-Random Read von 64 MB, und hier gibt es eine Leistungssteigerung von 200%! Beeindruckend!

Beim Schreiben von 64 MB Daten mit 32 Threads haben wir immer noch eine Leistungssteigerung von 75 %.

Compile Bench simuliert die Auswirkung des Alters auf ein Dateisystem, dargestellt durch die Manipulation von Kernelbäumen (Erstellen, Kompilieren, Patchen usw.). Hier sehen Sie einen signifikanten Vorteil durch die anfängliche Erstellung des simulierten Kernels, etwa 40%.

Dieser Benchmark misst einfach, wie lange es dauert, den Linux-Kernel zu extrahieren. Hier gibt es keine allzu große Leistungssteigerung.

Zusammenfassung

Die Anpassungen, die wir an der vorkonfigurierten ext4-Konfiguration von Ubuntu vorgenommen haben, zeigten eine beachtliche Wirkung. Die größten Leistungssteigerungen waren in den Bereichen Multithread-Schreib- und -Lesevorgänge, kleine Dateilesevorgänge und große zusammenhängende Dateilese- und -schreibvorgänge zu verzeichnen. Tatsächlich war der einzige wirkliche Punkt, an dem wir einen Leistungseinbruch sahen, bei einfachen Dateisystemaufrufen, worauf Samba-Benutzer achten sollten. Insgesamt scheint es eine ziemlich solide Leistungssteigerung für Dinge wie das Hosten von Webseiten und das Ansehen/Streamen großer Videos zu sein.

Denken Sie daran, dass dies speziell bei Ubuntu Natty 64-Bit war. Wenn Ihr System oder Ihre SSD unterschiedlich ist, kann Ihre Laufleistung variieren. Insgesamt scheint es jedoch so, als ob die von uns vorgenommenen Anpassungen von fstab und IO-Scheduler einen großen Beitrag zu einer besseren Leistung leisten, daher ist es wahrscheinlich einen Versuch auf Ihrem eigenen Rig wert.

Sie haben eigene Benchmarks und möchten Ihre Ergebnisse teilen? Haben Sie eine andere Optimierung, von der wir nichts wissen? Laut in den Kommentaren!

Continue Reading
Click to comment

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Tendencia