SSD (Solid State Disk)

Posted by on 06 Mar 2012 | Tagged as: hyper_ch, KDE, Ubuntu

So, nachdem ich vor kurzem wieder mal auf Chrome/ium gewechselt habe, hatte ich die ganze Zeit Probleme mit Ram. Es ist einfach ein extremer Ressourcenfresser. Ich habe schlussendlich die Konsequenz daraus gezogen und mir ein neues Notebook mit mehr Ram zugelegt (nun 8GB). Zudem verfügt es über eine SSD (Solid State Disk).

Da ich grundsätzlich alles verschlüssle, war sodann die Frage, ob es hier gewissen Optimierungsbedarf gibt, da SSDs eine andere Technik darstellen. Nachfolgend erläutere ich, was ich alles gemacht habe.

Blockgrösse Anpassung
Um die beste Performance aus der SSD herauszuholen ist es wichtig, dass die Blockgrösse und Sektoren optimal gewählt werden. Dazu mit einer Live-CD aufstarten und folgenden Befehl ausführen:

sudo fdisk -l /dev/sda | grep sectors

Das Resultat dürfte dann etwas so aussehen: 255 heads, 63 sectors/track, 4865 cylinders
Mit nachfolgendem Befehl dann die entsprechenden Daten verwenden:
sudo fdisk -H 255 -S 63 /dev/sda

Die Live-CD noch nicht auswerfen, da nachfolgend auch gerade noch partitioniert und das verschlüsselte Volume erstellt wird.

 

Partitionierung
Die enthaltene SSD verfügt nur über 160GB Kapazität. Ich habe mir die Frage gestellt, ob ich überhaupt SWAP anlegen soll. Ich bin der Meinung, dass 8GB Ram zur Zeit ausreichen und SWAP nicht notwendig ist. Der Nachteil dabei ist, dass das Gerät nicht in Hibernation Mode gesetzt werden kann. Ich benutz Hibernation sowieso nicht und mit der SSD dauert beim Aufstarten die Eingabe des Verschlüsselungskeys am längsten. Ich habe somit eine 200MB Partition für /boot geschaffen und der Rest ist root “/”.
Immer noch in der Live-CD dann gParted (oder was ähnliches starten) und die Partitionierung vornehmen.

 

Verschlüsselte Volumes
Da die SSDs extrem schnell sind und auch neuere Prozessoren AES-NI (zumindest die von Intel) haben, kann auch die das Standard-Payload von Luks angepasst werden. Standardmässig verwendet der Kernel ein 1MB Payload (IIRC), bei SSDs können wir dies auf 4MB erhöhen:

cryptsetup luksFormat --align-payload=8192 /dev/sda2

In diesem Beispiel ist sda2 natürlich meine zukünftige root Partition. Allenfalls können auch die sonstigen Luks / dm-crypt Optionen noch angepasst werden.

 

Installation starten
Nun kann die Kubuntu Alternate Install CD verwendet werden. Bei der Partitionierung auf manuell umstellen. Für die root Partition dann ein “encrypted volume” auswählen und dann im Setup für die verschlüsselten Partitionen kann “activate” ausgewählt werden. Damit wird die zuvor mit der Live-CD erstellte verschlüsselte Partition aktiviert – man braucht nur das Passwort einzugeben. Täte man das nicht, habe ich noch nicht gesehen, wie ich den “–align-payload=8192” Parameter während der Installation verwenden kann.

 

TMPFS erstellen
Da die SSDs ja nur eine begrenzte Wiederbeschreibbarkeit haben, ist zu überlegen, ob gewisse temporäre Verzeichnisse nicht in ein “Ram-Drive” geladen werden sollen. Ich bin zum Schluss gekommen, dass mit 8GB Ram, ich mir das leisten kann. Auf der anderen Seite, soll ja die Wiederbeschreibbarkeit extrem zugenommen haben – also das es nicht absolut notwendig wäre.
Deshalb: Nach der Installation wieder mit der Live-CD starten (ich will ja nicht unnötig Abnutzung erzeugen und dann folgendes in die /etc/fstab eintragen:

tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/log tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0

Damit werden diese drei Verzeichnisse in Ram geladen. Vorsicht: K3B und andere Programme könnten grosse Dateien nach /tmp schreiben. Die könnte dazu führen, dass zuwenig Ram vorhanden ist. Also immer zuerst prüfen.

 

Optmierung der fstab Einträge für /boot und root “/”
Wenn wir gerade dabei sind, die fstab zu bearbeiten, so müssen die Standardeinträge für /boot und root “/” noch angepasst werden. Diese sehen bei mir so aus:

/dev/mapper/sda2_crypt / ext4 noatime,nodiratime,discard,data=ordered,errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /boot ext4 noatime,nodiratime,discard,data=ordered 0 2

 

Chromium Cache nach /tmp verlagern
Wer sich sein System mal ein bisschen anschaut, der merkt, dass /etc/chromium noch eine default Datei vorhanden ist. Wenn man die öffnet, dann sieht man unter anderem folgendes:

CHROMIUM_FLAGS=""

Hier kann man also Chromium mitteilen, dass man noch ein paar gewünschte Parameter dazu haben will. Dies ist insofern praktisch, als dass man diese dann nicht mehr per Hand oder sonstigen Script aufzurufen braucht. Auf dieser Seite gibts jede Menge dieser Parameter: http://www.chromeplugins.org/tips-tricks/chrome-command-line-switches/
Ich habe diese Zeile also wie folgt geändert:
CHROMIUM_FLAGS="--disk-cache-dir=/tmp/cache/chromium --disk-cache-size=102400000  --memory-model=low"

Zuerst sage ich, dass Chromium den Cache auch ins /tmp folder legen soll. Bei einem Reboot ist der Weg und macht somit auch keine Schreibzyklen auf der SSD. Dann sage ich, dass der Cache max. 100 MB sein soll (na ja, nahe dran an 100MB) und zuletzt sage ich auch hier, dass Chromium Ram wieder freigeben soll, wenn möglich.

Ich habe jetzt diese Settings einige Tage benutzt und zwischendurch auch mal ein 64bit Windows 7 mit 1.5 GB ram in VBox laufen lassen und hatte bisher keine Probleme.

Bei Chrome scheint das allerdings nicht zu gehen, da ich keine globale Config Datei gefunden habe. Wer eine solche kennt, oder noch ein paar andere nützliche Command Line Switches kennt, bitte melden.

 

Kernel Optionen
Ebenfalls kann auch noch der I/O Scheduler für die SSD optimiert werden. Dazu muss zuerst das Paket sysfsutils installiert werden:

sudo apt-get install sysfsutils

Und danach die /etc/sysfs.conf anpassen, indem folgendes hinzugefügt wird.:

block/sda/queue/scheduler = noop

 

Apache Problem
Ich musste sodann feststellen, dass Apache nicht startet, wenn gewisse Verzeichnisse nicht vorhanden sind. Das ist irgendwie dämlich – ist nun aber so. Jedoch gibt es Abhilfe hiezu, indem man /etc/init.d/apache2-tmpfs bearbeitet und folgendes einfügt:

#!/bin/bash
#
### BEGIN INIT INFO
# Provides: apache2-tmpfs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Required-Start:
# Required-Stop:
# Short-Description: Create /var/log/apache2/error.log on tmpfs at startup
# Description: Create /var/log/apache2/error.log needed by Apache.
### END INIT INFO
#
# main()
#
case "${1:-''}" in
'start')
# create the /var/log/apache2/error.log needed by apache
mkdir /var/log/apache2
chmod 777 /var/log/apache2
touch /var/log/apache2/error.log
chmod 777 /var/log/apache2/error.log
;;
'stop')
;;
'restart')
;;
'reload'|'force-reload')
;;
'status')
;;
*)
echo "Usage: $SELF start"
exit 1
;;
esac

Danach muss dieses Script noch ausführbar gemacht werden:

sudo chmod 0755 /etc/init.d/apache2-tmpfs

Und beim Aufstarten und Heruntergefahren ausgeführt werden:

update-rc.d apache2-tmpfs defaults 90 10

 

Weitere Optimierung
Es könnte noch weitere Optmierungen vorgenommen werden wie die Deaktivierung des Journaling oder ähnliche Sachen. Diese sind mir aber zu “gefährlich”, weswegen ich darauf verzichte. Nachfolgend aber noch ein paar Links mit entsprechenden Infos:

https://wiki.ubuntu.com/MagicFab/SSDchecklist
https://wiki.archlinux.org/index.php/Solid_State_Drives#Encrypted_partition
http://bernaerts.dyndns.org/linux/50-compactflash-tune-apache

Tags: , , , , , , , , , , , , , ,

No Comments »

Comments are closed.