--- title: "Swap, zram oder nichts? Was bei 1 GB RAM wirklich hilft" date: 2026-11-13T12:31:58+01:00 modified: 2026-11-13T12:31:58+01:00 category: cloud type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/mini-server-swap-zram-1gb-ram-messung keywords: - Mini-Server - Swap - zram - OOM-Killer - WordPress - Lasttest - netcup reading_time: 10 ai_notice: "Mit KI erstellt – redaktionelle Prüfung ausstehend" --- # Swap, zram oder nichts? Was bei 1 GB RAM wirklich hilft > Mit KI erstellt – redaktionelle Prüfung ausstehend ([KI-Transparenz](https://s-edv.com/ki-transparenz)) Ein frisch installierter Server mit Ubuntu 24.04 bei netcup hat keinen Swap. Bei 1 GB RAM stellt sich deshalb schnell die Frage: Eine Swapdatei anlegen, zram einschalten oder es lassen? Diese Anleitung richtet beides ein und misst auf einem netcup VPS piko G11s mit einer vCPU, was es bringt. Gemessen wurde zweimal: einmal mit ruhendem Speicher, der sich gut auslagern lässt, einmal mit WordPress unter Überlast, wo der Speicher ständig gebraucht wird. **Dies ist Teil 5 der Reihe „Mini-Server“.** WordPress läuft wie in Teil 3 im Standard-Image mit MariaDB. **Kurzfassung:** Swap hilft, solange der ausgelagerte Speicher ruht. Ohne Swap beendete der OOM-Killer einen Speicherfresser schon bei 384 bis 512 MiB, mit einer Swapdatei von 1 GiB erst bei 1.408 bis 1.536 MiB, WordPress lief bis dahin ungestört. zram schaffte 768 MiB bei halber und 1.024 MiB bei voller RAM-Größe, weil der komprimierte Speicher selbst RAM belegt. Bei echter Überlast rettet Swap WordPress nicht: Bei 10 Aufrufen pro Sekunde war die Seite in jeder Variante minutenlang weg. Im Lauf mit Swapdatei blieb SSH aber erreichbar, und der OOM-Killer griff nicht ein. zram mit voller RAM-Größe fing sich nach 32 Minuten nicht und brauchte einen Neustart. Empfehlung: Swapdatei mit 1 GiB plus Grenzen für den Webserver wie in Teil 3. ## Was Sie brauchen - [ ] Einen Linux-Server mit 1 GB RAM, Root-Zugang und rund 1 GB freiem Plattenplatz, hier Ubuntu 24.04 auf dem Mini-Server aus [Teil 1](https://s-edv.com/anleitungen/mini-server-1gb-ram-leerlauf-docker-messung). - [ ] Für die Messung: WordPress mit MariaDB wie in [Teil 3](https://s-edv.com/anleitungen/mini-server-wordpress-1gb-ram-lasttest-oom) und einen zweiten Rechner mit k6 als Lastgenerator wie in [Teil 2](https://s-edv.com/anleitungen/mini-server-caddy-statische-website-lasttest-k6). Lasttests nur auf eigenen Systemen. - [ ] Zugang zur Server-Verwaltung Ihres Anbieters, um einen festgefahrenen Server hart neu zu starten. ## Schritt 1: Prüfen, ob Swap läuft Zuerst sehen Sie nach, ob der Server schon Swap hat: ```bash # swapon --show # free -m ``` Gibt `swapon --show` nichts aus und steht in der Zeile `Swap:` von `free -m` überall 0, läuft kein Swap. So war es auf dem Mini-Server nach der Installation. Wie stark der Speicher gerade unter Druck steht, zeigt die Datei `/proc/pressure/memory`: Der Wert `avg10` in der Zeile `some` gibt an, wie viel Prozent der letzten 10 Sekunden mindestens ein Prozess auf Speicher gewartet hat. ```bash # cat /proc/pressure/memory ``` > **Prüfen:** **Verifizieren:** Ohne Swap sieht `free -m` direkt nach dem Start mit WordPress so aus: > > ```plaintext > total used free shared buff/cache available > Mem: 957 423 218 3 451 534 > Swap: 0 0 0 > ``` ## Schritt 2: Eine Swapdatei anlegen Die Swapdatei ist 1 GiB groß, nur für root lesbar und wird über `/etc/fstab` bei jedem Start eingebunden: ```bash # fallocate -l 1G /swapfile # chmod 600 /swapfile # mkswap /swapfile # echo '/swapfile none swap sw 0 0' >> /etc/fstab # systemctl reboot ``` `mkswap` meldet `Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)`. Der Neustart prüft gleich mit, ob der Eintrag in `/etc/fstab` greift. Den Wert `vm.swappiness` lassen Sie auf dem Standard 60, alle Messungen liefen damit. > **Prüfen:** **Verifizieren:** Nach dem Neustart zeigt `swapon --show` die Datei mit Priorität -2: > > ```plaintext > NAME TYPE SIZE USED PRIO > /swapfile file 1024M 0B -2 > ``` ## Schritt 3: zram einrichten zram legt einen Swap-Bereich im RAM an und komprimiert alles, was dorthin ausgelagert wird. Unter Ubuntu richtet das Paket `systemd-zram-generator` das Gerät bei jedem Start ein. Haben Sie Schritt 2 ausgeführt, schalten Sie die Swapdatei vorher ab und entfernen sie aus `/etc/fstab`, damit wie im Test nur eine Variante läuft: ```bash # swapoff /swapfile # sed -i '\#^/swapfile #d' /etc/fstab # rm /swapfile # apt-get install -y systemd-zram-generator # printf '[zram0]\nzram-size = ram / 2\ncompression-algorithm = zstd\n' > /etc/systemd/zram-generator.conf # systemctl reboot ``` `zram-size = ram / 2` ist die halbe RAM-Größe. Wichtig für die Einordnung: Die Größe begrenzt die Daten vor dem Komprimieren. Was zram tatsächlich an RAM belegt, ist der komprimierte Teil plus Verwaltung. Im Test lief neben der halben auch die volle RAM-Größe mit `zram-size = ram`. > **Prüfen:** **Verifizieren:** `swapon --show` zeigt `/dev/zram0` mit Priorität 100, `zramctl` den Algorithmus und den Füllstand: > > ```plaintext > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > /dev/zram0 zstd 478,5M 4K 64B 20K 1 [SWAP] > ``` ## So wurde gemessen Jede Variante startete nach einem Neustart: ohne Swap, Swapdatei mit 1 GiB, zram mit halber und mit voller RAM-Größe. Auf dem Server lief WordPress mit MariaDB und Caddy im Zustand aus Teil 3, also das Standard-Image mit bis zu 150 Apache-Prozessen, ohne Speichergrenzen und ohne Seiten-Cache. Nach dem Start waren rund 440 bis 530 MiB verfügbar. Ein Skript schrieb alle 2 Sekunden, unter Last seltener, den verfügbaren Speicher, die Belegung von Swap und zram, den Speicherdruck aus `/proc/pressure/memory` und die Zahl der OOM-Kills mit. **Test 1, ruhender Speicher:** k6 rief vom zweiten Server 16 Minuten lang zwei Aufrufe pro Sekunde ab, verteilt auf 21 WordPress-Seiten. Nach 2 Minuten begann ein kleines Python-Programm, Speicher zu belegen: jede Minute weitere 128 MiB, bis zu 1.536 MiB. Es liest dafür echte Daten, ein Archiv der Programmdateien aus `/usr`, damit zram nicht mit leicht komprimierbaren Nullen geschönt wird. Der Speicher wird einmal gefüllt und dann nicht mehr angefasst, wie bei einem Dienst, der selten gebraucht wird. **Test 2, Überlast:** Nach 30 Sekunden Aufwärmen mit einem Aufruf pro Sekunde schickte k6 zwei Minuten lang 10 Aufrufe pro Sekunde. Der Server schafft ohne Cache rund 4. Apache startet dann immer neue Prozesse, die alle gleichzeitig Speicher brauchen. Ein Skript auf einem dritten Rechner fragte alle 15 Sekunden per SSH den Zustand ab und rief eine Seite auf. ## Ergebnis 1: Ruhender Speicher ![Balkendiagramm: gehaltener Ballast bis zum OOM-Kill, ohne Swap 384 MiB, zram halbe RAM-Größe 768, zram volle RAM-Größe 1.024, Swapdatei 1 GiB 1.408 MiB](https://s-edv.com/uploads/2026/11/747a2f3150c9c7053074b6e425dac9bec0fb84ea2922b852ba5ce19fc5fd158d-1024.png) *Gehaltener Ballast bis zum OOM-Kill: ohne Swap 384, zram halbe Größe 768, zram volle Größe 1.024, Swapdatei 1.408 MiB* Ohne Swap war bei 384 MiB Ballast noch 47 MiB Speicher verfügbar, beim Schritt auf 512 MiB beendete der OOM-Killer das Python-Programm. WordPress und MariaDB überlebten, die Seite stand dabei rund 10 Sekunden, 13 Aufrufe liefen in die Zeitgrenze von 10 Sekunden. | Variante | Gehalten bis zum OOM-Kill | Antwortzeit p95 davor | Aussetzer beim OOM-Kill | | --- | --- | --- | --- | | Ohne Swap | 384 MiB | 219 bis 254 ms | rund 10 s | | zram, halbe RAM-Größe | 768 MiB | 219 bis 241 ms | rund 90 s | | zram, volle RAM-Größe | 1.024 MiB | 217 bis 353 ms | keine Zeitüberschreitung | | Swapdatei 1 GiB | 1.408 MiB | 233 bis 266 ms | rund 15 s | Mit der Swapdatei lagerte der Kernel den ruhenden Speicher Stufe um Stufe aus, bis die Datei mit 1.023 MiB voll war. Die Antwortzeiten von WordPress blieben dabei praktisch gleich, 95 % der Aufrufe waren nach höchstens 266 Millisekunden fertig, kein einziger Fehler. Erst als nichts mehr ging, griff der OOM-Killer, rund 15 Sekunden lang kamen keine Antworten. zram hielt aus zwei Gründen weniger: Die Größe begrenzt die Daten vor dem Komprimieren, und die komprimierten Daten liegen selbst im RAM. Bei halber RAM-Größe war das Gerät mit 475 MiB voll, belegt waren dafür 159 MiB RAM. Bevor der OOM-Killer eingriff, war WordPress in diesem Lauf rund 90 Sekunden lang nicht erreichbar, der Speicherdruck stieg auf 94 %. Mit voller RAM-Größe gab es beim OOM-Kill keine Zeitüberschreitung. Das lange Hängen trat damit nur in einem von zwei zram-Läufen auf. ![Balkendiagramm: zram-Kompression, Speicher unter Überlast 478 MiB in 75 MiB RAM, Programmdateien 956 MiB in 340 MiB RAM](https://s-edv.com/uploads/2026/11/6e13df8dcbb23e6a4ba17e1ea814a01043f012d54a6fc6685e5e99d3c40c195b-1024.png) *zram-Kompression: Speicher unter Überlast Faktor 6,4, Programmdateien Faktor 2,8* Wie viel zram zurückgibt, hängt vom Inhalt ab. Die Programmdateien aus dem Test packte zstd mit Verwaltung auf gut ein Drittel. Den ausgelagerten Speicher im zweiten Test, fast nur Apache-Prozesse, verkleinerte es 5,6- bis 6,6-fach. ## Ergebnis 2: WordPress unter Überlast ![Balkendiagramm: Minuten bis die Webseite nach der Überlast zurück war, ohne Swap 9,8 und 5,0, zram halbe Größe 2,9, zram volle Größe nach 32 Minuten nicht zurück, Swapdatei 4,9](https://s-edv.com/uploads/2026/11/785a6778082372e3ca906fc3a058c5b97f40cc620f4596bd1305f86660839505-1024.png) *Überlast: Webseite nach Lastende weg, ohne Swap 5 bis 10 Minuten, zram volle Größe über 32 Minuten, Swapdatei knapp 5 Minuten* Bei 10 Aufrufen pro Sekunde scheiterten in jeder Variante rund 98 % der Aufrufe. Swap macht den Server nicht schneller, er kann nur entscheiden, wie der Server die Überlast übersteht. **Ohne Swap** fror der Server in beiden Läufen ein. Der verfügbare Speicher fiel auf 0, SSH antwortete rund 6 und 11 Minuten lang nicht, bis auf einzelne Antworten. Der OOM-Killer beendete jeweils zweimal MariaDB, Docker startete sie neu. Danach fing sich der Server von selbst, die Webseite kam 5 und 10 Minuten nach Lastende zurück. **Mit der Swapdatei** blieb SSH die ganze Zeit erreichbar, langsam, aber bedienbar. Apache erreichte seine Obergrenze von 150 Prozessen, bis zu 905 MiB lagen im Swap. Der OOM-Killer griff kein einziges Mal, MariaDB lief durch. Die Webseite war trotzdem bis knapp 5 Minuten nach Lastende weg, bis Apache die ausgelagerten Prozesse abgearbeitet hatte. Danach blieben 193 MiB im Swap liegen, das ist normal und stört nicht. **zram mit halber RAM-Größe** war voll, bevor Apache seine Obergrenze erreichte. SSH fiel knapp 3 Minuten aus, der OOM-Killer beendete einmal MariaDB, die Seite war knapp 3 Minuten nach Lastende zurück. **zram mit voller RAM-Größe** war der schlechteste Fall. zram war mit 957 MiB voll und belegte dafür 171 MiB RAM. Der Kernel lagerte nur noch ein und aus, die Last stieg auf 177, der OOM-Killer griff zu spät. Der OOM-Killer beendete zweimal MariaDB, die Apache-Prozesse blieben aber stehen. 32 Minuten nach Lastende war die Seite immer noch nicht erreichbar, SSH nur in einzelnen Momenten. Erst ein harter Neustart über die Server-Verwaltung half. ## Was das für Ihren Server heißt Eine Swapdatei mit 1 GiB lohnt sich auf einem Server mit 1 GB RAM: Selten genutzter Speicher wandert auf die Platte, und bei Überlast bleibt der Server per SSH bedienbar, ohne dass der OOM-Killer die Datenbank beendet. Gegen Überlast selbst hilft sie nicht. Dafür braucht der Webserver Grenzen: In [Teil 3](https://s-edv.com/anleitungen/mini-server-wordpress-1gb-ram-lasttest-oom) blieb der Server mit 8 Apache-Prozessen und Speichergrenzen für die Container bei Überlast bis 15 Aufrufe pro Sekunde jederzeit erreichbar. zram ist auf einem Server mit Platte und 1 GB RAM die schwächere Wahl. Es kostet RAM, der bei 1 GB knapp ist, und mit voller RAM-Größe hielt es den OOM-Killer so lange fern, dass sich der Server festfuhr. Die halbe RAM-Größe schnitt im Test besser ab als die volle, aber auch dort fielen SSH und die Datenbank kurz aus. Jede Variante lief einmal. ## Typische Fehler **SSH meldet `Connection to … port 22 timed out`, die Webseite antwortet nicht** Der Speicher ist voll, der Kernel ist nur noch mit Auslagern oder dem OOM-Killer beschäftigt. Ohne Swap fing sich der Server im Test nach rund 6 bis 11 Minuten. Mit zram in voller RAM-Größe half nach 32 Minuten nur ein harter Neustart über die Server-Verwaltung des Anbieters. **Im Kernel-Protokoll steht `Out of memory: Killed process … (mariadbd)`** Der OOM-Killer hat die Datenbank beendet, WordPress antwortet in dieser Zeit mit einem Fehler. Docker startet den Container mit `restart: unless-stopped` neu, `docker inspect -f '{{.RestartCount}}' NAME` mit dem Namen des Datenbank-Containers zeigt, wie oft. Abhilfe sind Grenzen für Apache und die Container wie in Teil 3 und eine Swapdatei. **`zramctl` zeigt bei `DATA` viel mehr als bei `TOTAL`** Das ist richtig so. `DISKSIZE` ist die Obergrenze und `DATA` die Menge der unkomprimierten Daten, `TOTAL` der tatsächlich belegte RAM. `free` zeigt in der Zeile `Swap:` die unkomprimierte Menge. **Nach der Last bleibt Swap belegt** Der Kernel holt ausgelagerte Seiten erst zurück, wenn sie gebraucht werden. Im Test blieben nach der Überlast 193 MiB in der Swapdatei, der Server lief normal. ## Häufige Fragen ### Wie groß sollte die Swapdatei bei 1 GB RAM sein? Gemessen wurde 1 GiB. Damit hielt der Server rund 1 GiB mehr ruhenden Speicher als ohne Swap, und bei Überlast war sie mit 905 MiB fast voll, ohne dass der OOM-Killer eingreifen musste. ### Sollte ich vm.swappiness ändern? Alle Messungen liefen mit dem Standardwert 60. Ob ein anderer Wert hier besser wäre, wurde nicht verglichen. ### Wie erkenne ich, dass mein Server zu wenig Speicher hat? Am Speicherdruck in `/proc/pressure/memory`. Mit der Swapdatei und ruhendem Speicher blieb `some avg10` unter 11 %, und WordPress antwortete normal. Beim Einfrieren stand er bei 94 bis 100 %. ## Fazit Eine Swapdatei mit 1 GiB ist auf einem Mini-Server mit 1 GB RAM die beste der drei Varianten. Mit ihr passte im Test rund 1 GiB mehr selten genutzter Speicher auf den Server, ohne WordPress zu bremsen, und hielt den Server bei Überlast per SSH bedienbar. zram brachte weniger zusätzlichen Platz und fuhr sich mit voller RAM-Größe unter Überlast fest. Keine der Varianten rettet WordPress, wenn mehr Aufrufe kommen, als die eine vCPU schafft. Dafür braucht es Grenzen für Apache und die Container wie in Teil 3. Weiter geht es in der Reihe mit Speichergrenzen pro Container: wer zuerst stirbt, wenn man nichts begrenzt, und wie man es steuert. ## Weiterführende Anleitungen und Quellen - [Mini-Server Teil 1: Was bleibt von 1 GB RAM übrig?](https://s-edv.com/anleitungen/mini-server-1gb-ram-leerlauf-docker-messung) - [Mini-Server Teil 2: Wie viele Aufrufe schafft ein Kern?](https://s-edv.com/anleitungen/mini-server-caddy-statische-website-lasttest-k6) - [Mini-Server Teil 3: WordPress auf 1 GB RAM](https://s-edv.com/anleitungen/mini-server-wordpress-1gb-ram-lasttest-oom) - [Mini-Server Teil 4: Vier kleine Dienste auf 1 GB RAM](https://s-edv.com/anleitungen/mini-server-uptime-kuma-vaultwarden-ntfy-adguard-1gb-ram) - [Docker Compose unter Linux](https://s-edv.com/anleitungen/docker-compose-linux-selfhosting-grundlage) - [Linux-Kernel: zram](https://docs.kernel.org/admin-guide/blockdev/zram.html) - [systemd zram-generator](https://github.com/systemd/zram-generator) - [Linux-Kernel: Pressure Stall Information](https://docs.kernel.org/accounting/psi.html)