Es gibt viele Tipps zum Optimieren Ihrer SSD unter Linux und viele Einzelberichte darüber, was funktioniert und was nicht. Wir haben unsere eigenen Benchmarks mit einigen spezifischen Verbesserungen durchgeführt, um Ihnen den wirklichen Unterschied zu zeigen.
Benchmarks
Zum Benchmarking unserer Festplatte haben wir die verwendet Phoronix Test Suite . 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 unter Verwendung der Standardparameter für das ext4-Dateisystem getestet.
Unsere Systemspezifikationen waren wie folgt:
- AMD Phenom II Quad-Core bei 3,2 GHz
- MSI 760GM E51 Motherboard
- 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 bei Amazon.com zum Zeitpunkt des Schreibens).
Prominente Verbesserungen
Es gibt einige Änderungen, die beim Upgrade auf eine SSD empfohlen werden. Nachdem wir einige der älteren Dinge herausgefiltert hatten, haben wir eine kurze Liste von Optimierungen erstellt, die Linux-Distributionen nicht als Standardeinstellungen für SSDs enthalten haben. Bei drei davon müssen Sie Ihre fstab-Datei bearbeiten. 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 wenn Sie die Funktionsweise auffrischen möchten, schauen Sie sich das an HTG erklärt: Was ist die Linux-Tabelle und wie funktioniert sie?
Zugriffszeiten vermeiden
Sie können die Lebensdauer Ihrer SSD verlängern, indem Sie den Schreibvorgang des Betriebssystems auf die Festplatte reduzieren. Wenn Sie wissen müssen, wann zuletzt auf jede Datei oder jedes Verzeichnis zugegriffen wurde, können Sie Ihrer Datei / etc / fstab diese beiden Optionen 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.
TRIM aktivieren
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, auch auf Standardfestplatten. Sie müssen über eine Kernel-Version von mindestens 2.6.33 oder höher verfügen. Sie sind versichert, wenn Sie Maverick oder Natty verwenden oder Backports für Lucid aktiviert haben. Dies verbessert zwar nicht speziell das anfängliche Benchmarking, sollte jedoch langfristig zu einer besseren Leistung des Systems führen und hat unsere Liste erstellt.
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 die folgende Zeile am Ende Ihrer / etc / fstab-Datei in einer neuen Zeile hinzu:
tmpfs / tmp tmpfs Standardeinstellungen, noatime, mode = 1777 0 0
Speichern Sie Ihre fstab-Datei, um diese Änderungen zu übernehmen.
IO-Scheduler wechseln
Ihr System schreibt nicht alle Änderungen sofort auf die Festplatte, und mehrere Anforderungen werden in die Warteschlange gestellt. Der Standard-Eingabe-Ausgabe-Scheduler - cfq - behandelt dies in Ordnung, aber wir können dies in einen ändern, der für unsere Hardware besser funktioniert.
Listen Sie zunächst mit dem folgenden Befehl auf, welche Optionen Ihnen zur Verfügung stehen, und ersetzen Sie "X" durch den Buchstaben Ihres Root-Laufwerks:
cat / sys / block / sdX / queue / scheduler
Meine Installation ist auf sda. Sie sollten einige 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 problemlos verwenden können. Wir müssen das Betriebssystem anweisen, diese Optionen nach jedem Start zu verwenden, damit wir die Datei rc.local bearbeiten können.
Wir verwenden Nano, da wir mit der Befehlszeile vertraut sind. Sie können jedoch auch einen beliebigen anderen Texteditor verwenden (gedit, vim usw.).
Plötzlich / Etc / rc.ぉ oder l
Fügen Sie über der Zeile "Ausgang 0" diese beiden Zeilen hinzu, wenn Sie die Frist verwenden:
Echo-Frist> / 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, um zu speichern, und STRG + X, um den Vorgang zu beenden.
Neu starten
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 oben genannten Schritte systematisch rückgängig machen, bis Sie erneut booten können. Sie können sogar eine verwenden LiveCD oder LiveUSB zum Wiederherstellen falls Sie es wollen.
Ihre fstab-Änderungen werden sich auch während Upgrades über die gesamte Lebensdauer Ihrer Installation erstrecken, aber Ihre rc.local-Änderung muss nach jedem Upgrade (zwischen den Versionen) erneut durchgeführt werden.
Benchmarking-Ergebnisse
Um die Benchmarks durchzuführen, haben wir die Disk-Testsuite ausgeführt. Das obere Bild jedes Tests befindet sich vor dem Optimieren der ext4-Konfiguration und das untere Bild nach den Optimierungen und einem Neustart. Sie erhalten eine kurze Erläuterung der Testmaßnahmen 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 rund 40%.
IOzone simuliert die Leistung des Dateisystems, in diesem Fall durch Schreiben einer 8-GB-Datei. Wieder ein Anstieg von fast 50%.
Hier wird eine 8 GB-Datei gelesen. Die Ergebnisse sind fast die gleichen wie ohne Anpassung von ext4.
AIO-Stress testet die Eingabe und Ausgabe asynchron mithilfe einer 2-GB-Testdatei und einer Datensatzgröße von 64 KB. Hier steigt die Leistung im Vergleich zu Vanilla ext4 um fast 200%!
Operationen mit kleinen Dateien
Eine SQLite-Datenbank wird erstellt und PTS fügt 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 konnte die Leistung um 25% gesteigert werden.
PostMark simuliert 25.000 Dateitransaktionen, jeweils 500 gleichzeitig, mit Dateigrößen zwischen 5 und 512 KB. Dies simuliert Web- und Mailserver ziemlich gut und wir sehen eine Leistungssteigerung von 16% nach dem Optimieren.
FS-Mark untersucht 1000 Dateien mit einer Gesamtgröße von 1 MB und misst, wie viele Dateien in einer festgelegten Zeit vollständig geschrieben und gelesen werden können. Unsere Optimierungen nehmen bei kleineren Dateigrößen erneut zu. Etwa 45% mehr mit ext4-Anpassungen.
Dateisystemzugriff
Die Dbench-Benchmarks testen Dateisystemaufrufe von Clients, ähnlich wie Samba die Dinge macht. Hier wird die Leistung von Vanilla ext4 um 75% reduziert, was einen großen Rückschlag für die von uns vorgenommenen Änderungen darstellt.
Sie können sehen, dass mit steigender Anzahl von Clients die Leistungsunterschiede zunehmen.
Mit 48 Kunden hat sich die Lücke zwischen beiden etwas geschlossen, aber es gibt immer noch einen sehr offensichtlichen Leistungsverlust durch unsere Optimierungen.
Mit 128 Clients ist die Leistung nahezu gleich. Sie können argumentieren, dass unsere Optimierungen für diese Art von Betrieb möglicherweise nicht ideal für den Heimgebrauch sind, aber eine vergleichbare Leistung bieten, wenn die Anzahl der Kunden stark erhöht wird.
Dieser Test hängt von der AIO-Zugriffsbibliothek des Kernels ab. Wir haben hier eine 20% ige Verbesserung.
Hier haben wir einen zufälligen Multithread-Lesevorgang von 64 MB, und hier wird die Leistung um 200% gesteigert! Beeindruckend!
Beim Schreiben von 64 MB Daten mit 32 Threads können wir die Leistung immer noch um 75% steigern.
Compile Bench simuliert die Auswirkung des Alters auf ein Dateisystem, wie durch Manipulieren von Kernelbäumen (Erstellen, Kompilieren, Patchen usw.) dargestellt. 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 keine allzu große Leistungssteigerung.
Zusammenfassung
Die Anpassungen, die wir an der sofort einsatzbereiten ext4-Konfiguration von Ubuntu vorgenommen haben, hatten erhebliche Auswirkungen. Die größten Leistungssteigerungen wurden im Bereich des Schreibens und Lesens mit mehreren Threads, des Lesens kleiner Dateien und des Lesens und Schreibens großer zusammenhängender Dateien erzielt. Tatsächlich war der einzige wirkliche Ort, an dem wir einen Leistungseinbruch sahen, einfache Dateisystemaufrufe, auf die 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 mit Ubuntu Natty 64-Bit war. Wenn Ihr System oder Ihre SSD unterschiedlich ist, kann Ihr Kilometerstand variieren. Insgesamt scheint es jedoch so, als ob die von uns vorgenommenen Anpassungen von fstab und IO-Scheduler einen großen Beitrag zur Verbesserung der Leistung leisten. Daher ist es wahrscheinlich einen Versuch wert, ein eigenes Rig zu verwenden.
Haben Sie eigene Benchmarks und möchten Sie Ihre Ergebnisse teilen? Haben Sie noch eine Optimierung, von der wir nichts wissen? Sound out in den Kommentaren!
