Habe gerade das hier gesehen 🫣:
„ACHTUNG! Dieser Bereich ist nur für Themen rund um unsere Community. Dazu gehören Mitglieder, das Forum selbst usw. Fragen zu Linux oder Hardware gehören hier nicht hin.“
Bitte verschieben oder löschen Sie diesen Beitrag und korrigieren Sie meine Antwort. Entschuldigung!
Vorbemerkung: Diesen Artikel habe ich vor einigen Jahren geschrieben. Ich teile ihn hier vollständig, allerdings ohne die ursprünglichen Links. Die Übersetzung aus dem Englischen stammt von einer KI, daher bitte ich etwaige Fehler oder holprige Formulierungen zu entschuldigen. Passt den Text gerne an, damit er bestmöglich ins Forum passt.
Faustregel / TL;DR: Wenn dein System nur gelegentlich Swap nutzt und es genügt, den Swap-Bedarf innerhalb von etwa 20 bis 30 % des physischen RAM als zram abzudecken, ist ZRAM die einfachere und wirksamere Option. Geht die Swap-Nutzung aber regelmäßig weit darüber hinaus, ist sie unvorhersehbar oder verfügt das System über schnellen Speicher (NVMe), dann ist Zswap die bessere Wahl. Zswap komprimiert heiße Pages dynamisch und hält sie im RAM, lagert kalte Pages in den Disk-Swap aus und liefert unter hoher Last ein gleichmäßigeres Verhalten.
Jahrelang habe ich zram als das beste swapbezogene Feature gepriesen, das man auf einem Linux-Desktop aktivieren kann. Wenn ein System anfängt, Speicher auszulagern, schreibt klassischer Swap ganze Pages auf den Datenträger, was im Vergleich zu RAM quälend langsam ist. Zwischen 2017 und 2020 habe ich mehrere Beiträge geschrieben, die erklärten, wie man zram auf Servern, Desktops und sogar auf Raspberry-Pi-Boards konfiguriert.
ZRAM verworfen und eine Zeit lang nur eine 32-GB-Swap-Datei genutzt.
Nach dem Entfernen von ZRAM und der Umstellung auf eine reine 32-GB-Swap-Datei.
Obwohl zram bereits 2014 aus dem Staging-Bereich des Kernels befördert wurde, haben die meisten gängigen Linux-Distributionen es erst um 2020 herum standardmäßig aktiviert. Man musste das zram-Modul weiterhin selbst laden und das Blockgerät mit Werkzeugen wie zram-config oder zram-tools einrichten.
Inzwischen bringen immer mehr Linux-Distributionen Zram und Zswap bereits mit, bei manchen ist eines von beiden standardmäßig aktiviert.
Indem zram Speicherseiten komprimiert und in einem Blockgerät im RAM ablegt, verschaffte es mir auf vielen Systemen mit wenig freiem Speicher genau den Spielraum, den ich brauchte. Auf Servern mit langsamen Festplatten (HDDs) und auf Desktops mit günstigen oder älteren SSD-Modellen fühlte sich ZRAM wie Magie an.
Spulen wir ein paar Jahre vor. Meine tägliche Workstation hat immer noch nur 16 GB RAM, aber meine Workloads sind gewachsen. Virtuelle Maschinen, Dutzende Browser-Tabs verteilt über mehrere Arbeitsflächen, Container, Editoren, Remmina, Termius, Gimp, Spotify und so weiter bedeuten, dass ich routinemäßig 20 GB Speicher verbrauche. Im Juli 2023 habe ich den Speicher in Desktop und Laptop auf sehr schnelle Hynix-NVMe-SSDs umgerüstet.
In diesem Kontext bekam meine alte Liebe zu zram Risse. Nach einigem Experimentieren und viel Recherche bin ich zu dem Schluss gekommen, dass zswap auf modernen Desktops oft die bessere Wahl ist als zram. Dieser Beitrag erklärt, warum zswap zram überlegen sein kann, und teilt die Erfahrungen aus einigen Jahren Praxiseinsatz.
Um zu verstehen, warum ich zram einst so stark propagiert habe, hilft ein Blick darauf, was es tut und warum es damals sinnvoll war. Der Linux-Kernel enthält ein zram-Modul, aber die meisten Distributionen aktivieren und konfigurieren es nicht automatisch. Lädt man es und initialisiert mit zramctl ein Blockgerät, entsteht ein komprimiertes Blockgerät im RAM, das sich wie eine Festplatte formatieren lässt.
Nutzt man dieses Gerät als Swap, werden auszulagernde Pages auf etwa 50 bis 30 % ihrer ursprünglichen Größe komprimiert und im Arbeitsspeicher (RAM) abgelegt, statt auf einen Datenträger geschrieben zu werden. Da das Gerät im RAM liegt, ist der Zugriff deutlich schneller als das Lesen oder Schreiben auf einem physischen Laufwerk. Die Kernel-Dokumentation beschreibt zram als Mechanismus, der RAM-basierte Blockgeräte erzeugt, deren geschriebene Pages komprimiert und im Speicher selbst abgelegt werden. Das reduziert den Verschleiß des Datenträgers und kann die effektive Speicherkapazität deutlich erhöhen.
In meinen früheren Beiträgen habe ich empfohlen, zram etwa 25 % des physischen RAM zuzuweisen. Auf einem 16-GB-System ergab ein 4-GB-zram-Block bei einem typischen Kompressionsverhältnis von 2:1 rund 8 GB komprimierte Swap-Kapazität. Zusammen mit den verbleibenden 12 GB RAM standen so effektiv etwa 20 GB nutzbarer Speicher zur Verfügung.
Wenn meine Workloads auf langsamen SSDs liefen, blieb die Maschine trotz starken Swappings reaktionsfreudig. Besonders attraktiv ist zram, wenn kein plattenbasiertes Swap-Gerät vorhanden ist, denn es lässt sich vollständig im Speicher einrichten und benötigt keine bereits vorhandene Partition.
Zur Einrichtung gehören die Installation des Pakets zram-tools, die Dimensionierung des Geräts (typischerweise 20 bis 30 % des RAM) sowie das Tuning von vm.swappiness und vfs_cache_pressure. Genau deshalb fühlte sich zram auf langsamen Datenträgern wie Magie an, und deshalb waren 25 % für viele Systeme der Sweet Spot.
Die Flitterwochen mit zram endeten, als meine Workloads über ein paar Gigabyte Swap-Nutzung hinauswuchsen. Irgendwann nutzte ich routinemäßig mehr als 10 GB Swap zusätzlich zu 16 GB physischem Speicher. Ein klarer Fall für mehr RAM, oder? Nun, ich möchte in diese Kiste nicht weiter investieren. Nächstes Jahr soll ein neuer Rechner her, und dort möchte ich 32 GB RAM verbauen. Bis dahin muss meine Workstation meine Last überstehen.
Nach meiner früheren Formel habe ich das zram-Gerät auf 8 GB (50 % des RAM) erhöht, was bei einem Verhältnis von etwa 2:1 bis zu 16 GB komprimierten Swap ergeben konnte. Anders als eine echte Partition reserviert zram diesen Speicher nicht im Voraus. Unter meinen schweren Workloads füllte sich das Gerät jedoch, sodass etwa 8 GB physischer RAM von komprimiertem Swap belegt waren. Damit blieben nur 8 GB für Working Set und Caches, was früher als zuvor zu Speicherdruck führte. Wenn zram voll war und der Kernel auf die Platte auslagern musste, brach die Performance ein.
Zwei Anmerkungen:
Ich bin außerdem auf einen Sonderfall gestoßen: Mit zram auf der Hälfte meines RAM führten Suspend-to-RAM (Schlafmodus) und das Aufwachen daraus gelegentlich zu kompletten Systemhängern. Einen offiziellen Bugreport kann ich dazu nicht nennen, aber die Kernel-Dokumentation weist darauf hin, dass zram nur begrenzt skaliert, da das komprimierte Gerät durch den verfügbaren RAM beschränkt ist und Kompression sowie Dekompression CPU-Overhead verursachen.
Kurz gesagt: Wer einem fest dimensionierten zram-Gerät zu viel Speicher zuweist, nimmt dem System den Arbeitsspeicher, den es für Suspend/Resume, I/O, Dateicaches und andere Kernel-Aufgaben braucht.
Am besten stellt man die Kompromisse direkt nebeneinander. Beide Techniken tauschen CPU-Zeit gegen weniger Disk-I/O. Wenn ein Workload kaum Swap berührt oder sich der Swap-Bedarf bequem durch das Komprimieren einiger Gigabyte decken lässt, ist zram eine elegante, einfache Lösung. Ist die Swap-Nutzung dagegen groß und unvorhersehbar, oder steht ein schnelles NVMe-Laufwerk zur Verfügung, sorgen der Write-behind-Cache und der dynamische Pool von zswap für ein gleichmäßigeres Erlebnis.
| Merkmal | ZRAM | Zswap |
|---|---|---|
| Hauptanwendungsfall | Kleiner oder gleichmäßiger Swap; langsamer Speicher | Großer oder sprunghafter Swap; schnelle SSD/NVMe |
| Funktionsweise | Komprimiertes, RAM-basiertes Swap-Gerät | Komprimierter RAM-Cache vor dem Swap |
| In swapon sichtbar? | Ja (/dev/zramX) | Nur der zugrunde liegende Swap |
| Ist es ein Swap-Gerät? | Ja (Blockgerät) | Nein (Cache) |
| Funktioniert ohne Disk-Swap? | Ja | Nein |
| Speicherverhalten | Feste Obergrenze; komprimiert alle ausgelagerten Pages | Dynamisch; wächst unter Druck, schrumpft im Leerlauf |
| Disk-I/O | Vermeidet Plattenzugriffe, bis das Gerät voll ist | Reduziert Schreibvorgänge; lagert kalte Pages auf die Platte aus |
| CPU-Kosten | Höher (jede ausgelagerte Page wird komprimiert) | Oft geringer (Cache plus Eviction) |
| OOM-Verhalten | Verzögert OOM, bis das Gerät voll ist | Verzögert OOM; lagert bei Erreichen der Poolgrenze auf die Platte aus |
| Stellschrauben | Gerätegröße, Priorität, Kompressor | max_pool_percent, Kompressor |
| Faustregel | Kleiner, gleichmäßiger Swap auf langsamem Speicher | Großer oder unvorhersehbarer Swap, oder schnelle NVMe |
| Kennzahl (System mit 16 GB RAM) | 1,5:1 | 2:1 | 3:1 |
|---|---|---|---|
| Wahrscheinlicher Algorithmus bei diesem Verhältnis | LZ4 | LZO | Zstd |
| ZRAM (4 GB) | |||
| Maximale Größe des ZRAM-Geräts (GB) | 4,00 | 4,00 | 4,00 |
| Maximal unkomprimiert in zram gespeichert (GB) | 4,00 | 4,00 | 4,00 |
| Ungefähr von zram belegter RAM, wenn voll (GB) | 2,67 | 2,00 | 1,33 |
| Für alles andere verbleibender RAM (GB) | 13,33 | 14,00 | 14,67 |
| Maximaler unkomprimierter Working Set vor dem ersten Disk-Swap (GB) | 17,33 | 18,00 | 18,67 |
| ZSWAP (Poolgrenze 20 % des RAM = 3,20 GB) | |||
| zswap-Poolgrenze (GB) bei 20 % | 3,20 | 3,20 | 3,20 |
| Maximal unkomprimiert in zswap gecacht (GB) | 4,80 | 6,40 | 9,60 |
| Ungefähr von zswap an der Poolgrenze belegter RAM (GB) | 3,20 | 3,20 | 3,20 |
| An der Poolgrenze für alles andere verbleibender RAM (GB) | 12,80 | 12,80 | 12,80 |
| Maximaler unkomprimierter Working Set vor dem ersten Disk-Swap (GB) | 17,60 | 19,20 | 22,40 |
Anmerkungen
Warum also der Titel dieses Beitrags? Ganz einfach: Meine realen Anforderungen und meine Hardware haben sich geändert. In den letzten Jahren verfügen zum Beispiel alle Systeme, mit denen ich arbeite, über schnellen Speicher, SSDs oder besser. Dazu kommen folgende Überlegungen:
Ich erkläre zram keineswegs für überholt. Es gibt Szenarien, in denen zram das richtige Werkzeug bleibt:
Wie sieht meine aktuelle Konfiguration aus? Auf meinem Desktop habe ich zram vollständig deaktiviert. In meiner /etc/default/grub steht zswap.enabled=1 zswap.compressor=lzo zswap.max_pool_percent=25. Meine 32-GB-Swap-Datei auf dem NVMe-Laufwerk habe ich auf 16 GB verkleinert. Das System bleibt auch unter hoher Last reaktionsfreudig und ist seit der Umstellung bei Suspend/Resume nicht mehr eingefroren.
Auf Servern setze ich weiterhin zram ein, allerdings nur mit 20 % des RAM. Wenn der Workload eines Servers darüber hinausgeht, ist das in der Regel ein Zeichen dafür, dass ich physischen Speicher nachrüsten oder Anwendungen tunen muss. Es versteht sich von selbst, aber: Unter keinen Umständen sollten wir zram 50 % des RAM zuweisen.
Als ich vor knapp drei Jahren meine Workstation und Gaming-Kiste gebaut habe, startete ich mit dem standardmäßigen 1 GB Disk-Swap und wechselte dann zu ZRAM. Anfangs brachte das spürbare Performance-Gewinne, doch mit wachsendem Speicherverbrauch und einem immer größeren RAM-Anteil für ZRAM litt die Performance. Besonders wegen des Fehlers, der das Aufwachen aus dem Schlafmodus verhinderte. Meine ursprüngliche NVMe war ein Budget-Kauf und etwa ein Drittel so schnell wie meine aktuelle.
Der nächste Schritt war, ZRAM komplett zu deaktivieren und eine große 32-GB-Swap-Datei anzulegen. Mit reichlich freiem Plattenplatz und einer schnellen NVMe blieb die Performance auch unter hohem Speicherdruck geschmeidig. So lief das einige Monate ohne Probleme.
Der einzige Grund, warum ich jetzt Zswap aktiviert habe, ist die Reduktion unnötiger NVMe-Schreibvorgänge und des damit verbundenen Verschleißes durch dauerhaft stark genutzten Swap. Auf einer schnellen NVMe geht es dabei mehr um Langlebigkeit und Best Practices als um Reaktionsfreudigkeit. Insgesamt war es eine Lektion: ZRAM passte zu diesem Workload, und zu vielen anderen, nicht so gut, wie ich einst glaubte. Langsame Datenträger findet man heute vor allem noch in Raspberry-Pi-Boards und anderen Budget-Geräten, denn auf gewöhnlichen Desktops und Servern sind sie seltener geworden.
Seine Meinung zu ändern kann demütigend sein, besonders nach einer Reihe von Blogbeiträgen, die etwas als „das Beste“ ausgerufen haben. Diese Artikel sind allerdings fast ein Jahrzehnt alt, und seitdem hat sich viel verändert: Meine Distributionen bringen Zram und Zswap inzwischen von Haus aus mit. Der Linux-Kernel bietet heute mehrere Werkzeuge zur Speicherkompression, und das richtige hängt von Hardware und Workload ab. Anders als vor zehn Jahren. Besonders Zstd hat sich zu einem sinnvollen Standard entwickelt.
Meine frühe Begeisterung für zram stammte aus dem Betrieb ressourcenbeschränkter Systeme und von Hardware mit langsamem Speicher. Für dieses Szenario bleibt es eine hervorragende Lösung. Auf einem modernen System liefert der dynamische komprimierte Cache von zswap jedoch gleichmäßigere Performance, besseres Verhalten beim Suspend und weniger Bastelei.
Scheu dich nicht, beides auszuprobieren: Beobachte deine Swap-Nutzung (swapon --show, free -h), teste verschiedene Poolgrößen und Kompressoren und vergiss vor allem nicht die einfachste Lösung von allen: mehr RAM einbauen.
Hi Toadie 😎 Ihr habt hier eine fantastische Community! Sie bietet so viel Tiefe – sei es bei den Artikeln, Anleitungen, Diskussionen, Community-Funktionen oder dem Gemeinschaftsgefühl.
Hallo zusammen! Ich habe Distro Fighter entwickelt. Ich wollte nur kurz sagen, dass ich kein Deutsch spreche. Aber aus Respekt übersetze ich meine Nachricht:
Ich möchte mich bei allen bedanken, die sich die Zeit genommen haben, Distro Fighter zu spielen und Feedback sowie Screenshots zu teilen.
Das war wirklich hilfreich – besonders die Screenshots. Ich weiß es sehr zu schätzen, dass ihr euch die Zeit zum Spielen genommen habt; danke, dass ihr Teil dieses Prozesses seid.
Es wurden einige kleine Anpassungen vorgenommen, um zu beheben, dass Debian und Ubuntu nicht in den Vorschlägen enthalten waren. Ich hoffe, dass die Empfehlungen und Bestätigungen für diejenigen, die ihre Wahl bereits getroffen haben, weiterhin korrekt bleiben.
