In den letzten Monaten ist mir aufgefallen, dass die Leistung meines Ultrabook mit der Zeit stark abnahm. Vorher war es kein Problem, 1 oder 2 virtuelle Maschinen nebenher laufen zu lassen – inzwischen war die Leistung aber so gering, dass es noch nicht einmal mehr möglich war, eine einzige VM laufen zu lassen und flüssig weiter zu arbeiten.
Natürlich habe ich die Systemauslastung beobachtet – mir ist aber nichts besonderes aufgefallen. Alle Werte lagen im mittleren Bereich mit Luft nach oben. Weder CPU noch RAM waren voll ausgelastet. Und trotzdem konnte man nicht mehr vernünftig arbeiten, wenn eine virtuelle Maschine in Hintergrund lief.
Heute morgen ist mir die Idee gekommen, doch mal die SSD genauer unter die Lupe zu nehmen. Wenn die schlechte Performance schon nicht an CPU und RAM lag, musste doch mit dem Speicher etwas nicht in Ordnung sein. Die Leserate war mit etwa 450 MB/s SSD-typisch hoch:
hdparm -t --direct /dev/sda
Die Messung der Schreibrate auf die System-SSD zeigt aber, warum mein System bei etwas höherer Beanspruchung so sehr in die Knie ging:
sync;time bash -c "(dd if=/dev/zero of=bf bs=8k count=500000; sync)"
Es wurden nur 16 MB/s beim Schreiben auf die verschlüsselte SSD gemessen. Das erklärte so manches. Aber wie war es möglich, dass die SSD auf einmal so langsam war?
Meine einzige Erklärung dafür war, dass die TRIM Funktion für SSDs nicht richtig eingerichtet war. Doch ein Blick in die /etc/fstab offenbarte, dass dort für die Systempartition bereits der „discard“ Parameter für TRIM gesetzt war. Was nun? Ich versuchte, einen manuellen TRIM auszuführen:
fstrim -v /
… was aber fehl schlug mit „discard operation not supported“. Da war klar: Aus irgendeinem Grund konnte TRIM nicht funktionieren. Ich hatte die SSD-Festplattenverschlüsselung im Verdacht, die ich mit dm-crypt und LUKS realisiere. Ein Blick in das Arch Wiki zum Thema dm-crypt zeigte, dass es bei einer verschlüsselten SSD nicht ausreichte, in der fstab „discard“ zu setzen. Neben dieser Maßnahme muss nämlich ein zusätzlicher Bootparameter angegeben werden. Ich nutze GRUB, also habe ich die Datei „/etc/default/grub“ bearbeitet und den „cryptdevice“ Teil um ein „allow-discards“ erweitert:
GRUB_CMDLINE_LINUX_DEFAULT="cryptdevice=/dev/sda4:main:allow-discards lang=de locale=de_DE.UTF-8 add_efi_memmap"
Danach wurde die neue GRUB Konfiguration geschrieben:
grub-mkconfig -o /boot/grub/grub.cfg
… und das Ultrabook neu gestartet.
Jetzt funktionierte auch der fstrim-Befehl und 50 GB Daten wurden in wenigen Sekunden auf der SSD optimiert:
Eine weitere Messung der Schreibrate auf SSD zeigte, dass die Leistung nun deutlich angestiegen war: 133 MB/s statt 16 MB/s. Nun kann ich auch wieder mehrere virtuelle Maschinen mit KVM nebenher laufen lassen, ohne dass der Bildschirm ständig einfriert.
http://micha.stoecker.me
Vielen Dank, bei mir war es noch nicht sooo schlimm, aber immerhin konnte ich die Schreibrate von 304 MB/s auf 435 MB/s steigern, sofern die Ausgabe von
dd
der Realität entspricht.http://micha.stoecker.me
Ach ja, ich würde im Beitrag
sync;time bash -c "(dd if=/dev/zero of=bf bs=8k count=500000; sync)"
noch umrm bf
erweitern, zwecks Aufräumen nach dem Test ;)http://micha.stoecker.me
Wow. Auf der /home-Partition auf meinem alten Notebook war der Unterschied schon größer, von 64 MB/s auf 373 MB/s.
http://blog.tuxinaut.de
Vielen Dank für den Beitrag :) Der hat doch sehr geholfen. Das ganze stand schon seit Monaten auf meiner TODO Liste der Beitrag hat mich bewogen mir mal die Zeit zu nehmen.
http://www.roboterkneipe.de
Ich nutze selbst eine SSD. Das Problem hatte ich selbst aber noch nicht. Dazu zwei Anmerkungen:
Trim sorgt zwar für eine höhere Performance, ist aber bei verschlüsselten Platten durchaus problematisch:
http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html
Muss man halt entscheiden, ob man damit leben kann und wie ausgeprägt die eigene Paranoia ist…
Soweit ich weiß, ist trim bei modernen SSDs nicht mehr unbedingt notwendig. Debian schreibt hierzu:
„The „discard“ options is not needed if your SSD has enough overprovisioning (spare space) or you leave (unpartitioned) free space on the SSD. “
Hat man zu wenig spare space, dann kann man das bei der Partitionierung einrichten, indem man einen Bereich unpartioniert lässt, wie bei Krenn beschrieben:
http://www.thomas-krenn.com/de/wiki/Solid_State_Drive#Spare_Area
Danke für diesen Beitrag. Leider komme ich nicht dadurch auf eine Verbesserung meiner Datenraten :(. Brandneue Samsung 850 PRO 256GB an SATA 3Gb/s installiert und Manjaro mit LUKS aufgesetzt. Meine Raten liegen ALLE unter der 150MB/s Linie… Bin echt ratlos. Liegt es etwa an der Verschlüsselung? Bin für jeden Tipp dankbar. LG
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Hi apali,
ich hab die Datenraten bei mir nochmal überprüft. Auf meinen beiden Arch Rechnern komme ich fast an die Geschwindigkeit ohne Verschlüsselung. Also ca 450 MB beim lesen und 350 MB beim schreiben. Vor dem Test habe ich „getrimt“. Wie gut die Performance bei der Entschlüsselung der Daten ist, hängt auch immer davon ab, wie stark die CPU ist bzw ob diese auf bestimmte Cryptoalgorithmen wie z.B. AES optimiert ist.
Wie gut deine CPU bestimmte Algorithmen verarbeiten kann, kannst du mit dem Kommando „cryptsetup benchmark“ überprüfen.
LG Thomas
Toller Beitrag, ich hatte das gleiche Problem unter einer anderen Distro. Gelöst habe ich es, in dem ich in der /etc/crypttab die discard-option angehängt habe. Bsp:
luks-9083e277-c4e9-4588-9297-1856baa35a3a UUID=9083e277-c4e9-4588-9297-1856baa35a3a none discard