Warum unsere Server ohne Swap laufen

Wer auf einem rack::SPEED-Server free -h ausführt, sieht in der Swap-Zeile eine Null — und viele Linux-Tutorials behaupten, das sei ein Konfigurationsfehler. Ist es nicht: Swap ist bei uns bewusst deaktiviert. Dieser Artikel erklärt die Gründe und zeigt, was bei knappem Arbeitsspeicher tatsächlich hilft.

Was Swap tut — und warum es aus der Zeit gefallen ist

Swap lagert Arbeitsspeicher-Inhalte auf den Datenträger aus, wenn der RAM voll ist. Das stammt aus einer Zeit, in der RAM knapp und teuer war: Lieber langsam weiterlaufen als gar nicht. Der Preis ist heftig — Datenträger sind selbst als NVMe um Größenordnungen langsamer als RAM. Ein Server, der ernsthaft swappt, arbeitet nicht mehr, er quält sich Thrashing: Das System ist fast nur noch damit beschäftigt, Speicherseiten zwischen RAM und Datenträger hin- und herzuschieben — statt echte Arbeit zu erledigen. .

Warum wir Swap deaktivieren

1. Swap versteckt Probleme, statt sie zu lösen. Ein swappender Server ist „oben”, aber unbenutzbar — Seiten laden sekunden- bis minutenlang, und das oft stundenlang unbemerkt. Ohne Swap gilt: Geht der Speicher aus, beendet der Kernel gezielt den größten Verbraucher ( OOM-Killer Out-of-Memory-Killer: Kernel-Mechanismus, der bei vollem Speicher den speicherhungrigsten Prozess beendet, damit das System handlungsfähig bleibt. ). Das ist ein klares, sofort sichtbares Signal — für dich und für unser Monitoring — statt eines schleichenden Leistungsverfalls.

2. Unsere Storage-Architektur ist dafür zu schade. Deine Server laufen auf verteiltem NVMe-Ceph-Storage — ausgelegt auf schnelle, echte Nutzdaten-Zugriffe. Dauerhaftes Swap-Geschreibe würde genau dort sinnlose Last erzeugen, ohne dass dein Projekt davon schneller wird.

3. RAM-Ehrlichkeit statt Illusion. Swap vergrößert deinen Arbeitsspeicher nicht — er kaschiert nur, dass er zu klein ist. Wenn ein Server regelmäßig an die RAM-Grenze läuft, ist die richtige Antwort mehr RAM oder sparsamere Dienste, nicht ein langsamer Ersatz-Speicher.

Was bei RAM-Engpässen wirklich hilft

1. Verbraucher identifizieren: Ressourcennutzung im Panel bzw. auf eigenen Servern docker stats und top.
2. Speicherfresser zähmen: Java-Heaps begrenzen (siehe das OpenSearch-Beispiel), Cache-Größen deckeln, ungenutzte Dienste stoppen.
3. Ehrlich aufstocken, wenn die Last echt ist: Server-Wechsel & Upgrade — RAM-Erweiterung klärt ein Ticket meist schnell.

Wenn etwas schiefläuft

Ein Tutorial oder Installer verlangt Swap

Viele Anleitungen prüfen stumpf auf vorhandenen Swap und warnen sonst — ein Relikt, kein echtes Hindernis.

Lösung: Die Warnung kannst du in aller Regel ignorieren; die Software läuft ohne Swap normal. Verweigert ein Installer hart den Dienst, Ticket öffnen — wir schauen uns den Fall an.

Ein Prozess wurde „einfach so” beendet

Vermutlich hat der OOM-Killer zugeschlagen — bei Containern zeigt sich das als Exit-Code 137.

Lösung: Den Speicherbedarf des Dienstes prüfen und begrenzen (Heap, Worker-Anzahl, Cache-Limits). Passiert es wiederholt bei normalem Betrieb, ist das RAM ehrlich zu klein — siehe oben.

Du hast Root und überlegst, Swap selbst zu aktivieren

Technisch möglich — empfehlen wir aber aus allen genannten Gründen nicht: Du tauschst ein sichtbares Problem gegen ein unsichtbares.

Lösung: Lieber die RAM-Frage klären (Ticket). Wenn du für einen Sonderfall dennoch Swap brauchst, sprich es an — dann finden wir eine Lösung, die die Plattform nicht belastet.

Verwandte Artikel

• Ressourcennutzung im Panel prüfen — wo dein Speicher tatsächlich hingeht.
• Server-Wechsel & Upgrade — der ehrliche Weg zu mehr RAM.
• OpenSearch im Container — Praxisbeispiel für gezähmte Speicherfresser.

Du kommst nicht weiter?

Speicher regelmäßig am Limit oder ein Dienst stirbt immer wieder? Ticket im Kundencenter öffnen — nenn Server und Zeitpunkte, wir schauen gemeinsam auf Verbraucher und Dimensionierung.