Ein Blog über Code, Hardware und Co

NAS, Server und Co

Synology: SWAP auf SSD auslagern

Oder: Ein Lösungsansatz, wenn der RAM knapp und das NAS langsam wird

Ein Synology NAS bietet unzählige Möglichkeiten und ist mehr ein kleiner Anwendungsserver denn eine reine Speicherlösung. Daher kommt es, dass viele Anwender – mich eingeschlossen – mit der Zeit immer mehr Dienste auf dem NAS laufen lassen. Dadurch kann der RAM (Arbeitsspeicher) knapp werden und das System beginnt zu “swappen” und das System wird wesentlich langsamer.

Die bessere Alternative: RAM aufrüsten

Vorweg sei eines klar gesagt: Swap ist mehr oder weniger eine Notlösung des Systems. Sobald der Arbeitsspeicher – der für den ordentlichen betrieb des Systems und der Anwendungen unabdingbar ist – knapp wird, beginnt das System, diesen Speicher mit Speicher auf der Festplatte zu erweitern.

Die Festplatte – und auch eine SSD – ist dabei um etliche Faktoren langsamer als RAM. Daher sollte mittelfristig immer ein RAM-Upgrade Priorität haben. Leider ist das bei einigen NAS nicht möglich, oder aber in der Höhe begrenzt.

Lösungsansatz: Swap auf einem SSD-Volume anlegen

Wer wie ich viele Anwendungen auf seinem NAS betreibt, der merkt, dass der RAM mit der Zeit knapp wird. Leider ist die Möglichkeit des Aufrüstens bei NAS oft begrenzt, oder zumindest aufwändig. Daher lässt sich mit einer SSD ein Engpass beheben.

Schritt 1: SSD-Volume erstellen.

Ich empfehle in jedem Fall ein internes Raid-Volume. Es geht aber auch mit einer per USB angeschlossenen SSD. Das Volume formatiere ich zunächst mit dem ext4 Dateisystem.

Abbildung 1: SSD mit ext4 formatieren.

Schritt 2: Swap-Datei auf SSD-Volume erzeugen

Wir öffnen (z.B. mittels Putty) ein Terminal und verbinden uns über SSH dem NAS. Wir navigieren nun in das SSD-Volume und erzeugen mit dem folgenden Befehl eine SWAP-Datei:

dd if=/dev/zero of=swapfile bs=1024k count=16000

Was macht der Befehl im Detail? Er erstellt mittels des Programms “dd” eine mit Nullen gefüllte Datei im Verzeichnis “swap” unterhalb des aktuellen Verzeichnisses. Die Größe der Datei beträgt 16.000 MB (1024kb = 1MB; 1MB*16000).

Schritt 3: Schreib und Zugriffsrechte der Datei anpassen

Da außer dem Systemuser root Niemand etwas in unserem Swap-File zu suchen hat, machen wir es mit dem folgenden Befehl nur für den Root-User nutzbar:

chmod 600 swapfile

Schritt 4: File in Swapfile umwandeln

Das erstellte und mit Rechten versehene File müssen wir nun in eine Auslagerungsdatei/ein Swapfile umwandeln. Das geht mit folgendem Befehl:

mkswap swapfile

Schritt 5: Swapfile einbinden

Mit dem folgenden Befehl binden wir nun das neue Swapfile ein und aktivieren es:

swapon swapfile

Das Swapfile wird nun dem bestehenden Swap hinzugerechnet. Ob das Einbinden des Swapfiles geklappt hat, sehen wir mit dem Befehl “free”. Hier wird nun die neue Swapgröße angezeigt. Mit dem Befehl “swapon -s” können wir sehen, welche Swap-Verzeichnisse oder -Files eingebunden sind.

Da wir nun aber unser reguläres Volume entlasten wollen, müssen wir mit folgendem Befehl noch den “alten” Swap entfernen:

swapoff /dev/md1

Fertig, das NAS muss nicht einmal neugestartet werden.


Achtung: Mögliche Nebenwirkungen und Einschränkungen

Nebenwirkung 1: Da in der SWAP-Datei viele Datenoperationen stattfinden und u.U. viele Daten geschrieben werden, kann es zu einer erhöhten Abnutzung der SSD kommen. Dies liegt daran, dass die Flash-Zellen von SSDs anders als die des RAM in der Anzahl der Schreibvorgänge beschränkt sind.

Real zeigt sich diese Abnutzung in den smart-werten, genauer gesagt dem Wert “wear _leveling_count”. Je häufiger eine Zelle beschrieben worden ist, desto höher steigt in der Regel dieser smart-Wert. Achtung, in DSM 6.x ist der “wear_leveling_count” die Grundlage, nach der das DSM entscheidet, ob die SSD “gesund” ist, oder mit einem kritischen Zustand markiert wird. Kritische SSD-Laufwerke können im NAS nicht mehr verwendet werden, weder als SSD-Cache noch als normales Volume! Das soll den Nutzer vor Datenverlust schützen, da SSDs im Falle eines “Absterbens” oft ohne Voranzeichen einfach ausfallen.
Tests haben jedoch gezeigt, dass auch Consumer-SSDs in der Regel weit mehr als die zugesicherten TBW aushalten (https://www.ontrack.com/de-de/blog/how-long-do-ssds-really-last).
Siehe hierzu auch: https://www.synology-forum.de/threads/ds918-ssd-cache-hat-tbw-grenze-erreicht-und-sind-jetzt-unbrauchtbar.95751/

Nebenwirkung 2: Diese Variante übersteht keinen Reboot. Nach einem Neustart des NAS wird wieder die Standard Swap-Partition genutzt. Damit der SSD-Swap einen Neustart übersteht muss man die fstab missbrauchen 😉

Einschränkung 1: Swap-Files werden im von Synology verwendeten Linux Kernel NICHT mit dem Btrfs Filesystem unterstützt. Auch in neueren Kernelversionen ist mit Einschränkungen zu rechnen. So ist es ab Kernel 5 so, dass auf Btrfs Volumes, auf denen Swap eingerichtet ist, keine Snapshots mehr möglich sind und die Einrichtung eines Swap-Files ohnehin nur möglich ist, wenn für das Volume Copy on Write nicht vorhanden ist.

Einschränkung 2: Auch wenn ich es bereits anders ausprobiert habe, bitte bitte das Swap-File nur auf ein Raid-SSD-Volume legen und nicht auf eine einzelne SSD. Die Gefahr, dass sonst die SSD irgendwann den Geist aufgibt und es zu Datenverlust im Swap kommt, ist sonst real.

Das Ergebnis: Leistungsvergleich

Da meine Volumeslots derzeit belegt sind, kann ich die Variante .
Die “Schwuppdizität” des Systems, vor allem des DSM nimmt merklich zu. Ebenfalls ist der “wait”-Wert nach Verlagerung des Swap-Speichers auf ein SSD-Volume merklich gesunken.

Abbildung 2: CPU-Auslastung vor der SWAP-Verlagerung. Der dunkelblaue Anteil des “wait”-Status ist deutlich zu sehen.
Abbildung 3: CPU-Auslastung nach der Swap-Verlagerung. Der Anteil des “wait”-Status hat deutlich abgenommen. Ergo: Die CPU muss seltener und weniger warten.

TLD;DR: Was ist eigentlich Swap?

Hier folgt in Kürze ein kurzer Exkurs: Vergleich der Geschwindigkeiten von HDD, SSD und RAM im Bezug auf die für Arbeitsspeicher/Swap so wichtigen Zugriffszeiten und Input-/Output-Operationen.


Weitere Fragen zum Swap auf Synology NAS

Wenn ich swapon -s eingebe, sehe ich dev/zram0 und dev/zram1 als swap-Partition. Was hat es damit auf sich?

zram ist eine Softwarelösung, die ein kleines komprimiertes Swapverzeichnis im RAM anlegt. Diese Swap-Partition wird mit hoher Priorität, also vor dem Swap auf Festplatte oder SSD verwendet. Da Daten, die vom RAM in den zram-swap verlagert werden, komprimiert werden, kann man durch diese Methode mehr Daten im RAM unterbringen. Da der zram-swap wesentlich schneller ist, als swap auf HDD oder SSD ist das System zudem schneller, solange in den zram geswappt wird. Allerdings sorgt zram für Last auf der CPU.

Ich erhalte beim Befehl “swapon” den Hinweis “insecure file user”

Dann hast Du das Swapfile mit einem anderen User als root erstellt bzw. es gehört einem anderen User. In diesem Fall einfach das swapfile mit dem Befehl “chown root:root swapfile” dem Nutzer root zuschreiben.

swapon failed: Operation not permitted

Das Einbinden eines Swapfiles ist dem User root bzw. Superuser vorbehalten. In diesem Fall “sudo swapon” nutzen. Selbiges gilt für “swapoff”.

Was ist der wait-Wert bei der CPU-Auslastung? Wieso ist er für swap relevant?

Der wait-Wert gibt an, wie oft sich die CPU anteilig im “wait”-Status befindet. Im wait-Status kann die CPU nicht weiter rechnen, da sie auf Daten von der Festplatte wartet. Je höher der wait-Anteil, desto langsamer wird das System, da die CPU ausgebremst wird. Ein größerer wait-Anteil ist ein Indiz dafür, dass das System swappt und der RAM knapp wird/ist.

Schreibe eine Antwort