Wie viel RAM benötigen Sie im Jahr 2025 wirklich für Server und VPS?

Die Dimensionierung des Arbeitsspeichers (RAM) ist eine Berechnung der Arbeitslast und kein Benchmark. Wenn Sie zu viel ausgeben, zahlen Sie für ungenutzte Kapazität. Wenn Sie zu wenig einplanen, werden Ihre Prozesse beendet, Ihre Datenbank wird von der Festplatte statt aus dem Arbeitsspeicher bedient oder Ihre Container werden gedrosselt. Dieser Leitfaden enthält konkrete RAM-Bereiche für die am häufigsten vorkommenden Workloads (Webhosting, Datenbanken, Virtualisierung, Container, KI-Inferenz und Spieleserver) sowie Regeln für die Dimensionierung von Workloads, die nicht in der Liste aufgeführt sind.

Die Funktion des Arbeitsspeichers (RAM) in einem Server

Der RAM speichert alles, womit der Server gerade aktiv arbeitet. Prozessspeicher für Webserver, Datenbank-Engines und Hintergrund-Daemons. Seiten-Cache auf Betriebssystemebene und Festplatten-E/A-Puffer. Laufzeitspeicher für Anwendungen und Container. Sowie die Speicherblöcke, die an virtuelle Maschinen oder Container-Workloads übergeben werden.

Was die Dimensionierung des RAM von der der CPU unterscheidet, ist der Ausfallmodus. Geht die CPU-Leistung aus, werden Prozesse verlangsamt. Geht der RAM aus, führt der Kernel entweder einen Swap durch (langsam) oder der OOM-Killer wählt ein Opfer aus und beendet es. Ersteres ist unangenehm. Bei der zweiten Option gehen Daten verloren. Die Bereitstellung von RAM mit einer Sicherheitsreserve ist kein „Nice-to-have“, sondern das, was verhindert, dass das System unter Last zusammenbricht.

RAM je nach Arbeitslast

Web- und Anwendungsserver

• Leichter LAMP- oder LEMP-Stack: 1 bis 2 GB
• WordPress oder CMS mit Caching (z. B. Redis): 2 bis 4 GB
• E-Commerce (Magento, WooCommerce): 4 bis 8 GB
• Node.js-, Django- oder Rails-Anwendungen: 2 bis 6 GB

Caching-Schichten wie Redis oder Varnish benötigen zusätzlich zum Basisbedarf der Anwendung eigenen Arbeitsspeicher. PHP-FPM-Worker, Datenbankverbindungen und Reverse-Proxys beanspruchen alle gleichzeitig Speicher, daher ist die Spitzenparallelität entscheidend und nicht der Speicherbedarf im Leerlauf.

Datenbankserver (SQL und NoSQL)

• MySQL oder PostgreSQL (klein): 4 bis 8 GB
• MySQL oder PostgreSQL (groß oder mit hohem Datenverkehr): 16 bis 64 GB
• MongoDB oder Redis (In-Memory-Fokus): 32 bis 128 GB oder mehr
• Elasticsearch- oder OpenSearch-Knoten: 32 bis 128 GB pro Knoten

Das Ziel besteht darin, den Arbeitsspeicher, die Indizes und die häufig abgerufenen Zeilen im RAM zu halten. Sobald auch nur ein Teil davon auf die Festplatte ausgelagert wird, vergrößert sich die Latenz um ein Vielfaches, ganz gleich, wie schnell die SSD ist.

Virtualisierungshosts (Proxmox, VMware, Hyper-V)

• Leichte Linux-VMs: 2 bis 4 GB pro VM
• Windows-VMs: 8 bis 12 GB pro VM
• Hosting-Panels (cPanel, Plesk, DirectAdmin): 4 bis 8 GB pro Instanz
• KVM- oder LXC-Container-Hosts: 32 bis 128 GB oder mehr

Reservieren Sie zusätzlich zu den Zuweisungen für die Gäste immer 4 bis 8 GB für das Host-Betriebssystem selbst. Container verbrauchen pro Workload weniger RAM als vollständige VMs, skalieren jedoch anders. Planen Sie daher eher mit Blick auf Dichte und Burst-Spielraum als auf die Größe pro Container. Wenn der Host ZFS verwendet, berücksichtigen Sie auch den ARC, der standardmäßig stillschweigend bis zur Hälfte des System-RAMs beansprucht und mit den Zuweisungen für Gäste konkurriert (unser Leitfaden zur ZFS-ARC-Optimierung behandelt die richtigen Obergrenzen für Hypervisor-Workloads).

Container und Microservices (Docker, Kubernetes)

• Einfache Docker-Stacks (Web, App, DB): 8 bis 16 GB
• Docker Swarm- oder K3s-Edge-Knoten: 16 bis 32 GB
• Kubernetes-Worker-Knoten: 32 bis 128 GB
• CI/CD-Runner und Build-Agenten (GitLab, Jenkins): 8 bis 32 GB pro Runner

Achten Sie bei lang laufenden Containern auf Speicherlecks. JVM-basierte Workloads wie Kafka und Elasticsearch benötigen höhere Basiswerte, da sich der Heap dort ansammelt, wo Sie ihn zulassen – was oft höher ist, als Sie erwartet haben.

KI- und ML-Inferenz

• Kleine Modelle (quantisiertes BERT, Llama 7B): 16 bis 32 GB
• Mittlere Modelle (13B bis 30B, quantisiert): 64 bis 128 GB
• Große Modelle (40B+ oder nicht quantisierte Modelle der mittleren Größenordnung): 128 bis 512 GB oder mehr
• GPU-gestützte Inferenz (Stable Diffusion, Whisper): 32 bis 128 GB, abhängig von der Auslagerung

Durch die Quantisierung verlagert sich die Speicherbelastung von der GPU auf den CPU-RAM, sodass sich die Systemanforderungen erheblich ändern, je nachdem, ob Sie fp16 auf der GPU oder 4-Bit auf der CPU ausführen. Auch die Batchgröße und die Länge der Prompts treiben die Zahlen in die Höhe. Unser Leitfaden zum Hosting von KI-Inferenz geht näher auf die Abstimmung von Hardware und Modellgröße ein.

Spieleserver

• Minecraft (Vanilla): 2 bis 4 GB
• Minecraft (mit Mods): 6 bis 16 GB
• Rust, ARK oder 7 Days to Die: 8 bis 16 GB
• Hosting-Knoten mit mehreren Instanzen: 32 bis 64 GB

Spezialisierte Workloads

• Videotranskodierung (FFmpeg, Plex): 16 bis 64 GB
• Backup- oder Snapshot-Server: 8 bis 16 GB, mehr bei Einsatz von Deduplizierungs-Engines
• Firewall oder IDS (pfSense, Suricata): 2 bis 8 GB, mehr bei NetFlow oder vollständiger Paketprotokollierung

Verlassen Sie sich nicht auf den Swap-Speicher

Swap ist 10- bis 100-mal langsamer als RAM. Er dient als Sicherheitsnetz, damit der Kernel bei plötzlichem Speicherengpass ausweichen kann, und nicht dazu, den nutzbaren Speicher zu erweitern. Wenn ein Server unter normaler Auslastung bereits auf den Swap zurückgreift, ist er schlichtweg unterdimensioniert – Punkt. Der Artikel „Wie Linux-Swap, der OOM-Killer und cgroups zusammenwirken“ behandelt die Fehlermodi im Detail.

So bestimmen Sie die RAM-Größe genau

1. Messen Sie Spitzenwerte, nicht Durchschnittswerte. Nutzen Sie htop, free -m, vmstat 1oder Ihre Kubernetes-Metriken, um die Spitzenauslastung über einen vollständigen Datenverkehrszyklus hinweg zu ermitteln. Tägliche Spitzen, wöchentliche Batches und monatliche Abrechnungsläufe spielen dabei alle eine Rolle.
2. Planen Sie Spielraum für Wachstum ein: 20 % bis 50 % für die Skalierung von Anwendungen. Bei Datenbanken sollten Sie den Arbeitsspeicher an die Größe des Datensatzes anpassen, nicht an die Anfragerate. Bei Multi-Tenant-Plattformen berechnen Sie den Speicherbedarf pro Kunde und multiplizieren Sie diesen Wert.
3. Planen Sie unter Berücksichtigung des Ausfallmodus, den Sie tolerieren können. Eine Lese-Replik mit zu wenig RAM arbeitet mit verminderter Leistung. Ein Datenbank-Primärserver mit zu wenig RAM führt zu fehlerhaften Abfragen und kann Anwendungen mit sich zum Absturz bringen. Setzen Sie den Arbeitsspeicher dort ein, wo die Auswirkungen am größten sind.

RAM ist die Komponente, bei der ein Mangel mehr schadet als eine Überdimensionierung. Das Hinzufügen von Arbeitsspeicher macht eine CPU-gebundene Anwendung nicht schneller, aber eine zu knappe Auslegung zerstört die Stabilität. Legen Sie die Größe anhand realer Überwachungsdaten und Ihrer getesteten Spitzenlasten fest und lassen Sie dann Spielraum.

FDC bietet dedizierte Server und VPS mit Konfigurationen mit hohem RAM-Speicher und unbegrenzter Bandbreite in mehreren Regionen an.