Swap, zram oder nichts? Was bei 1 GB RAM wirklich hilft

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.

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.
• Für die Messung: WordPress mit MariaDB wie in Teil 3 und einen zweiten Rechner mit k6 als Lastgenerator wie in Teil 2. 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:

# 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.

# cat /proc/pressure/memory

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:

# 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.

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:

# 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.

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

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.

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.

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

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 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?
• Mini-Server Teil 2: Wie viele Aufrufe schafft ein Kern?
• Mini-Server Teil 3: WordPress auf 1 GB RAM
• Mini-Server Teil 4: Vier kleine Dienste auf 1 GB RAM
• Docker Compose unter Linux
• Linux-Kernel: zram
• systemd zram-generator
• Linux-Kernel: Pressure Stall Information