RAM, das neue Gold? Wie IT-Teams den Speicher-Engpass mit Software entschärfen Software-Strategien gegen die Speicherknappheit

Anbieter zum Thema

FAST LTA GmbH

Wer in den vergangenen Monaten Server bestellt oder einen bestehenden Cluster aufgerüstet hat, kennt das Problem: Die Preise für DDR5-Module sind binnen weniger Quartale stark gestiegen. Ein 64-GB-DDR5-RDIMM dürfte bis Ende 2026 rund doppelt so viel kosten wie zu Beginn des Jahres 2025. Treiber ist der KI-Boom. Für IT-Verantwortliche wird das schnell zu mehr als einem reinen Kostenproblem.

Der RAM-Markt nach der KI-Welle

Die Knappheit hat strukturelle Ursachen. Samsung, SK hynix und Micron haben einen erheblichen Teil ihrer Fertigungskapazität auf High-Bandwidth-Memory (HBM) umgestellt, also auf jenen Speichertyp, den KI-Beschleuniger für Training und Inferenz brauchen. Nach Zahlen von TrendForce beanspruchen KI-bezogene Speicher (HBM und GDDR7) im Jahr 2026 rund 20 Prozent der weltweiten DRAM-Waferkapazität. Diese Kapazität fehlt im klassischen Server-DRAM-Markt, zumal HBM laut Branchenanalysen pro Gigabyte etwa die dreifache Waferfläche von DDR5 belegt. Hinzu kommen die anhaltend hohen Investitionen der Hyperscaler in eigene KI-Rechenzentren. IDC spricht in seiner Marktanalyse von einer permanenten Neuverteilung der DRAM-Fertigungskapazitäten zugunsten von KI, und Goldman Sachs rechnet damit, dass die Knappheit bis ins Jahr 2027 anhält.

Für den Betrieb von Virtualisierungs- und Storage-Clustern heißt das: Kapazitätsengpässe, die sich früher durch das Nachbestellen weiterer Module auflösen ließen, lassen sich heute nicht mehr ohne Weiteres beheben. Besonders betroffen sind hyperkonvergente Plattformen und Software-Defined-Storage-Architekturen, die auf reichlich Hauptspeicher angewiesen sind. ZFS-ARC, Caches und Metadaten-Pools belegen RAM dauerhaft. Damit wird RAM vom Nebenposten in der Stückliste zum strategischen Kostenfaktor.

Verdichten statt aufrüsten

Fast jeder produktive Hypervisor bringt seit Jahren Software-Hebel mit, die den vorhandenen Speicher besser ausnutzen, aber selten gezielt zum Einsatz kommen. Sie sind die günstigste Antwort auf steigende RAM-Preise und kosten keine zusätzliche Lizenz. Auf einem Proxmox-VE-Cluster holen sie, richtig kombiniert, deutlich mehr aus derselben Hardware heraus als eine Standardkonfiguration. Je nach Workload-Profil und Konfigurationsdisziplin lässt sich die VM-Dichte um 30 bis 300 Prozent steigern. Fünf Stellschrauben sind dabei besonders wirksam.

Kernel Samepage Merging: kostenlose Deduplizierung im Hauptspeicher

Kernel Samepage Merging (KSM) steckt seit über einem Jahrzehnt im Linux-Kernel und wird von KVM-basierten Hypervisoren wie Proxmox VE genutzt. Der Hintergrundprozess ksmd durchsucht laufend die Speicherseiten der virtuellen Maschinen nach identischen Inhalten. Findet er mehrere Seiten mit gleichem Inhalt, ersetzt der Kernel die Mehrfachkopien durch eine einzige Copy-on-Write-Referenz. Auf Servern mit vielen gleichartigen VMs, etwa mehreren identischen Windows-VMs oder Linux-Gästen aus demselben Template, liegt die Einsparung oft im zweistelligen Prozentbereich. Ohne diese Funktion stünde dieser Speicher auf der nächsten Bestellung.

VirtIO Memory Ballooning: dynamisch umverteilen

Die zweite, häufig unterschätzte Technik ist VirtIO Memory Ballooning. Damit kann der Hypervisor Speicher, der einer VM zwar zugewiesen ist, gerade aber brachliegt, im Betrieb zurückholen und einer anderen VM mit höherem Bedarf geben. Voraussetzung ist der VirtIO-Balloon-Treiber im Gastsystem. In Proxmox VE regeln das zwei Werte: eine feste Obergrenze und ein Minimum, unter das die VM nicht gedrückt wird. Der Dienst pvestatd leitet das Ballooning ein, sobald die RAM-Auslastung 80 Prozent übersteigt, und versucht, den Speicher auf diesen Standardwert zu regulieren. So lassen sich VMs großzügiger dimensionieren, ohne die Hardware am Worst Case ausrichten zu müssen.

In-Memory-Kompression: zram und zswap

Einen Schritt weiter geht die In-Memory-Kompression. Dafür gibt es zwei verwandte Verfahren. Zram stellt ein RAM-basiertes Block-Device als Swap bereit und legt die Speicherseiten transparent komprimiert ab, meist mit lz4 oder Zstandard (zstd). Kompressionsraten von Faktor vier bis fünf sind gut erreichbar; in unseren Messungen liegt der Faktor oft darüber. zswap arbeitet nach demselben Prinzip, lagert aber Seiten, die nicht mehr in den Cache passen, zusätzlich auf einen SSD- oder NVMe-Swap aus. Welches Verfahren besser passt, entscheidet das Workload-Profil. In beiden Fällen sollte „vm.swappiness“ explizit gesetzt sein; ein Wert von 10 funktioniert mit komprimiertem Swap erfahrungsgemäß gut.

Storage-Tuning: den ZFS ARC im Zaum halten

Wer ZFS als lokalen Datastore nutzt, und auf hyperkonvergenten Clustern ist das häufig der Fall, sollte den Adaptive Replacement Cache (ARC) im Auge behalten. Bei aktuellen Proxmox-VE-Installationen ist der ARC zwar auf 10 Prozent des Host-RAMs limitiert, ältere Set-ups oder Standard-ZFS-Installationen reservieren sich jedoch bis zur Hälfte des Hauptspeichers für diesen Lese-Cache. Sobald RAM knapp wird, ist das selten sinnvoll und kann im Extremfall sogar Out-of-Memory-Situationen auslösen, wenn VMs und ARC um denselben Speicher konkurrieren. Eine Daumenregel: den ARC über „zfs_arc_max“ auf 4 GB plus 1 GB je gespeichertem TB Nutzdaten begrenzen. Das schafft Luft für VMs und Container. Die transparente ZFS-Kompression mit lz4 oder zstd auf Dataset-Ebene senkt zusätzlich die Schreiblast und damit den IO-seitigen Speicherbedarf.

Architekturentscheidung: Container statt Vollvirtualisierung, wo es passt

Auch die Architektur lässt sich nutzen. Überall dort, wo eine Anwendung in einem Linux-Container laufen kann, entfällt pro Instanz der Speicher für ein komplettes Gastsystem. Ein KVM-Gast schleppt meist 100 bis 500 MB Kernel- und Treiber-Overhead mit; ein LXC-Container teilt sich den Host-Kernel und braucht für die Anwendung oft nur 10 bis 50 MB. Bei vielen gleichartigen Workloads wie Webservern, Build-Knoten oder schlanken Datenbanken summiert sich das rasch auf zweistellige Gigabyte-Beträge. Braucht ein Workload einen eigenen Kernel oder ein Nicht-Linux-System, bleibt die VM erste Wahl. Die Entscheidung für Container oder VM sollte gezielt und pro Workload fallen.

Fazit: Software vor Hardware

Die hohen RAM-Preise sind eine direkte Folge des KI-Booms und werden uns vermutlich noch eine Weile begleiten. Wer darauf allein mit Hardware reagiert, teurer einkauft oder Cluster überdimensioniert, verschenkt Möglichkeiten, die ohne zusätzliche Lizenzkosten bereitstehen. KSM, Memory Ballooning, In-Memory-Kompression, ein knapp gehaltener ZFS ARC und die passende Wahl zwischen Container und VM greifen einzeln und kombiniert. Unterm Strich ist das oft günstiger als der nächste Speicher-Upgrade-Zyklus, und es spricht für Software-Defined-Infrastrukturen, in denen Hardware und Software voneinander entkoppelt sind.

* Der Autor: Alwin Antreich ist Head of Training and Proxmox Services bei der croit GmbH in München. croit unterstützt Unternehmen weltweit beim Aufbau, Betrieb und Support von Ceph- und Proxmox-Infrastrukturen. Der Gastbeitrag basiert auf seinem Vortrag „RAM das neue Gold: Software-Strategien gegen die Speicher-Knappheit“, gehalten auf den ProxTalks 2026 in Wien.

(ID:50957901)