Auslagerung
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Hinweis:
Dieser Artikel ist Teil der Artikelserie SSD, welche das Thema Solid State Drives behandelt. Dieser Artikel geht in allen Beschreibungen davon aus, dass die SSD als /dev/sda im System eingebunden ist. Die Befehle müssen bei davon abweichenden Systemen daher gegebenenfalls angepasst werden.
Jedes Linux-System und dessen Anwendungen benötigt Speicherplatz für temporäre Daten. Temporäre Daten brauchen einen Systemabschluss („Ausschalten/Neustart“) nicht zu überstehen. Sie sind somit nicht persistent.
Für die Zwischenspeicherung temporärer Daten kann Linux wahlweise RAM oder Festplatten nutzen. Aus Geschwindigkeitsgründen (primär) und aus Haltbarkeitsgründen (sekundär) optimiert man die Schreibzugriffe auf die SSD. Programme nutzen dann RAM und/oder andere Festplatten des Systems. Dazu muss der Rechner einerseits über ausreichend Speicher in Form von RAM (empfehlenswert sind vier Gigabyte oder mehr – siehe 64-Bit-Architektur (Abschnitt „Wer-sollte-Ubuntu-64-bit-installieren“)) oder aber über weitere Festplatten verfügen.
Dies bringt zwei Vorteile beim Einsatz einer SSD:
Der Zugriff auf Daten im RAM ist um ein Vielfaches schneller als der Zugriff auf eine SSD
Es werden viele Schreibvorgänge von meist nur kleinen Dateien auf die SSD vermieden
Beispielsweise werden in der Linux-Verzeichnisstruktur temporäre Dateien in /tmp und in einigen Unterverzeichnissen von /var (z.B. /var/run, /var/lock) gespeichert. Die dort abgelegten Daten kann man bei Bedarf in andere Dateisysteme verlagern, die ggf. (nur) im schnellen RAM liegen und dafür aber mit dem Herunterfahren des Systems verloren gehen. Darüber hinaus benutzen einige Anwendungen einen eigenen Cache (siehe Firefox und Chromium), der sich ebenfalls verlagern lässt.
Hinweis:
Die Linux-typische Swap-Partition soll an dieser Stelle bewusst ausgeklammert werden. Sobald ein System bei normalem Betrieb öfter auslagert, sollte man zunächst in ausreichend RAM investieren, bevor man an eine SSD denkt.
Verlagerung von /tmp¶
Ob das Verlagern des /tmp Verzeichnisses ins RAM sinnvoll ist, muss im Einzelfall entschieden werden (siehe Auslagerungsspeicher). Sofern sich neben der SSD auch eine Festplatte im System befindet, kann /tmp wegen der vielen Schreibzugriffe darauf jedoch problemlos auf die Festplatte ausgelagert werden.
Hinweis:
Verlagert man Dateien und Ordner von /tmp ins RAM, so sollte man sich darüber im Klaren sein, dass diese nach einem Neustart nicht mehr verfügbar sind. Auch sollte man die Auslastung des RAM im Auge behalten, so dass dieses nicht überläuft. Dies trifft vor allem bei Brennprogrammen zu, die teilweise sehr hohe Datenmengen in /tmp zwischenspeichern. Des weiteren können in Mehrbenutzer-Systemen andere eingeloggte Anwender Zugriff auf eigene Dateien und Ordner in /tmp erhalten.
Mit dem nachfolgenden Befehl in einem Editor [1] kreiert man eine RAM-Disk in /etc/fstab [2] , die den Ordner /tmp aufnimmt:
tmpfs /tmp tmpfs nosuid 0 0
Dadurch wird eine dynamische RAM-Disk namens tmpfs für den Ordner /tmp erstellt und diesem standardmäßig maximal die Hälfte des RAM-Speichers zur Verfügung stellt. "Dynamische RAM-Disk" bedeutet, dass stets nur der aktuell darin belegte Platz vom verfügbaren RAM abgezwackt wird.
Die Änderungen werden nach einem Neustart des Systems oder per folgendem Befehl im Terminal [3] mit Root-Rechten [4] aktiviert:
sudo mount -a
RAM Größenbegrenzung für /tmp anpassen¶
Standardmäßig richtet das System eine RAM-Disk so ein, dass maximal die Hälfte des RAM belegt werden kann. Möchte man dieses Limit z.B. erhöhen um die Auslagerung der Daten vom RAM auf die Swap-Bereich zu vermeiden, so kann man dies auf zweierlei Art tun: Per absolutem oder prozentualem Wert. Die Werte werden wie folgt in /etc/fstab [2] konfiguriert:
absoluter Wert:
tmpfs /tmp tmpfs nosuid,size=2G 0 0
relativer Wert:
tmpfs /tmp tmpfs nosuid,size=15% 0 0
Im ersten Fall wird der fixe absolute Wert zwei Gigabyte (siehe Markierung) zugewiesen. An dieser Stelle kann man auch 512M für 512 Megabyte setzen. Im zweiten Fall wird der fixe relative Wert 15% (siehe Markierung) des RAM genutzt. Man kann ebenso auch jede andere Zahl eintragen wie z. B. 45%. Als grober Richtwert hat sich 15% bei vier Gigabyte RAM (entspricht 600 Megabyte) als ausreichend erwiesen. Dies ist natürlich subjektiv und vom Einsatzzweck abhängig.
RAM Größenbegrenzung von Shared Memory (shm)¶
Auch für die Interprozesskommunikation (IPC) nach dem POSIX-Standard richtet Ubuntu automatisch im Ordner /dev/shm eine RAM-Disk als Shared-Memory-Bereich ein. Dies kann man kontrollieren mit:
mount | grep shm
Es sollte die folgende Ausgabe zu sehen sein:
none on /dev/shm type tmpfs (rw,nosuid,nodev)
Standardmäßig kann von shm die Hälfte des RAM belegt werden. Die Auslastung kann man wie in Status beschrieben kontrollieren. Sollte tatsächlich eine zu hohe Auslastung vorliegen, kann man die maximale Größe mit einer Zeile in /etc/fstab [2] anpassen:
shm /dev/shm tmpfs nodev,nosuid,size=4G 0 0
Es wurde damit ein Bereich von vier Gigabyte für einen Shared Memory Bereich innerhalb des RAM zugewiesen. Die Änderungen werden nach einem Neustart des Systems oder per folgendem Befehl im Terminal [3] mit Root-Rechten [4] aktiviert:
sudo mount -a
Unterverzeichnisse von /var¶
Grundsätzlich möglich ist die Verlagerung der folgenden Verzeichnisse:
/var/cache
/var/games
/var/lock (ab Ubuntu 11.10: /run/lock)
/var/log
/var/run (ab Ubuntu 11.10: /run)
/var/tmp
Die Verlagerung von /var/cache, /var/games und /var/tmp ins RAM sollten abgewogen und den persönlichen Bedürfnissen angepasst werden. Bei Zweifeln sollte man die Verzeichnisse belassen wo sie sind. Hilfreich ist in jedem Falle ein Blick in Filesystem Hierarchy Standard 🇬🇧 .
Auch die Verlagerung von /var/log ins RAM sollte man sorgfältig abwägen, ob der geringfügige Vorteil durch die Verringerung der Schreibvorgänge die Nachteile aufwiegt, da bei jedem Herunterfahren bzw. Neustart sämtliche Logdateien des Systems unwiederbringlich verloren gehen.
/var/log im RAM bedeutet:
eingeschränkte Möglichkeiten zu Fehlerverfolgung (insbesondere nach Systemabstürzen)
keine Möglichkeit zur nachträglichen Analyse von Sicherheitsvorfällen
Von Paketen während der Installation erstellte Unterverzeichnisse gehen verloren
Verwenden installierte Programmpakete Unterverzeichnisse, wie beispielsweise Samba, so fehlen sämtliche Logdateien dafür. Schlimmer ist es etwa bei Apache 2: Der Start schlägt beim Versuch fehl, die Datei error.log zu öffnen. Erst das Erstellen des Unterverzeichnis mit den entsprechenden Rechten behebt das Problem.
Die Verlagerung geschieht wie gewohnt über die Datei /etc/fstab [2] , in die man die gewünschten folgenden Zeilen einfügt:
tmpfs /var/run tmpfs nosuid,mode=0755 0 0 tmpfs /var/lock tmpfs noexec,nosuid,nodev 0 0 tmpfs /var/log tmpfs noexec,nodev,nosuid 0 0
Hinweis:
Ab Kernel Version 2.6.35 (genutzt in Maverick) werden /var/run und /var/lock automatisch ins RAM ausgelagert. Eine Auslagerung ist hier nur noch für /var/log sinnvoll.
Achtung!
Auf keinen Fall darf man /var insgesamt ins RAM auslagern, denn dort werden für den Systembetrieb unverzichtbare Daten wie z.B. die der Paketverwaltung abgelegt. Eine Auslagerung auf Festplatte kann jedoch durchaus empfehlenswert sein, wenn eine Festplatte vorhanden ist und ohnehin läuft (SSD dient zur System-Beschleunigung).
Hinweis:
Das Problem, dass verlagerte Daten mit einen Neustart verloren gehen kann mit dem anything-sync-daemon gelöst werden (http://www.debian-administration.org/articles/661 https://github.com/graysky2/anything-sync-daemon). Dieser kopiert die Daten beim runterfahren etc. automatisch auf/von Festplatte.
Status von /tmp, /shm und /var¶
Hat man sich dazu entschieden auszulagern, kann man das Ergebnis wie folgt überprüfen. Dies ist ebenfalls sinnvoll, um die gemachten Einstellungen gegebenenfalls nach oben oder unten zu korrigieren. Mit dem Terminal-Befehl [3]
df -h
kann man nachschauen, ob die RAM-Disk und/oder der Shared Memory Bereich korrekt angelegt wurde. Die Ausgabe sieht in etwa wie folgt aus:
tmpfs 2,0G 28M 2,0G 1% /tmp shm 4,0G 3,9M 4,0G 0% /dev/shm none 3,9G 84K 3,9G 1% /var/run none 3,9G 0 3,9G 0% /var/lock tmpfs 2,0G 844K 2,0G 1% /var/log
Die Anzeige im einzelnen:
Die RAM-Disk tmpfs nimmt dabei maximal 2,0 Gigabyte an Platz auf dem 8 Gigabyte umfassenden RAM ein. In Gebrauch (und tatsächlich im RAM belegt) sind davon 28 Megabyte, so dass aufgerundet 2,0 Gigabyte verfügbar bleiben. 1% der RAM-Disk ist belegt und eingebunden ist sie als /tmp.
Der Shared Memory Bereich shm ist insgesamt 4,0 Gigabyte groß. 3,9 MB sind zurzeit in Gebrauch, so dass 4,0 Gigabyte verfügbar bleiben. 1% des Bereichs sind belegt und eigebunden ist der Bereich als /dev/shm.
Die dritte, vierte und fünfte Zeile zeigen die Verlagerung von /var/run, /var/lock und /var/log, die in diesem Fall ebenfalls in tmpfs gespeichert werden.
Verlagerung des Browser-Caches¶
Weil Internet-Browser häufig und viel in ihren Zwischenspeicher (Cache) schreiben, kann dieser in eine RAM-Disk verlagert werden. Mit einer Verlagerung geht jedoch mit jedem Neustart der gesamte Cache verloren. Dies kann mit dem profile-sync-daemon 🇬🇧, der den Cache beim Neustart automatisch auf/von Festplatte speichert/lädt, vermieden werden. Eine Anleitung zur Einrichtung findet man auf ubuntuforums.org 🇬🇧.
Firefox¶
Wie man den Browser-Cache von Firefox auslagert, steht im Artikel Firefox/Tipps (Abschnitt „Verlagerung-des-Browser-Caches“).
Chromium¶
Wie man den Browser-Cache von Chromium bzw. Google Chrome auslagert, steht im Artikel Chromium (Abschnitt „Verlagerung-des-Browser-Caches“).
Opera 12¶
Wie man den Browser-Cache von Opera 12.x auslagert, steht im Artikel Opera 12/Tipps (Abschnitt „Cache“).
Links¶