Wie viel RAM braucht ein VPS? Die Regel, Anwendung für Anwendung

Die Regel: addieren, was im Speicher bleibt

Ein Server verbraucht Arbeitsspeicher nicht „im Allgemeinen“: jedes laufende Programm belegt einen Teil davon, solange es läuft. Die Rechnung beginnt daher mit der Liste der Prozesse, die dauerhaft laufen, und addiert dann die Spitze und eine Reserve:

Einzuplanender Arbeitsspeicher = (System + dauerhafte Dienste + Spitze der gelegentlichen Aufgaben) × 1,25

• Das System: eine minimale Linux-Distribution (Debian, Ubuntu) belegt nach dem Start etwa 150 bis 300 MB, SSH-Zugang und Protokollierung inklusive.
• Die dauerhaften Dienste: Webserver, Prozesse der Anwendung, Datenbank, Cache, Job-Queue. Ihr Verbrauch hängt von der Technologie ab, die der nächste Abschnitt im Detail behandelt.
• Die Spitze: was zeitweise hinzukommt, etwa der Build einer Anwendung, ein Backup, ein Import, ein aufwendiger geplanter Job. Ein Server, der nach seinem Durchschnitt bemessen ist, fällt genau in diesen Momenten aus.
• Die Reserve: 25 % über der Summe, für das Wachstum von Daten und Traffic. Sie liegt nicht brach: Linux nutzt freien Speicher als Datei-Cache, was die Datenbank beschleunigt.

Was jeder Baustein verbraucht

Die folgenden Größenordnungen gelten für eine Anwendung üblicher Größe, gemessen in Produktion. Sie sind ein Ausgangspunkt; die Messung an Ihrer eigenen Anwendung, weiter unten beschrieben, hat immer das letzte Wort.

Eine Spitze kehrt bei JavaScript-Anwendungen immer wieder: der Build. npm run build braucht bei einem Next.js-, Nuxt- oder Angular-Projekt üblicherweise allein 1 bis 2 GB, einige Minuten lang, zusätzlich zu allem, was schon läuft. Auf dem Server zu bauen heißt, für diese Spitze zu bemessen; auf Ihrem Rechner oder in Ihrer CI-Pipeline zu bauen und nur das Ergebnis hochzuladen, heißt, sie zu vermeiden.

Dieselbe Überlegung gilt für Docker-Container: jeder Container ist eine Gruppe gewöhnlicher Prozesse, und der Docker-Daemon bringt seinen eigenen Verbrauch mit. docker stats zeigt, was jeder einzelne belegt.

Typische Profile

Diese Profile addieren die Bausteine von oben, Spitze und Reserve inklusive. Sie gehen von einer Anwendung üblicher Größe und dem Traffic eines Starts aus; eine umfangreiche Datenbank oder anhaltender Traffic verschieben den Wert nach oben.

Eine Anwendung, die ein KI-Modell per API aufruft (OpenAI, Anthropic, Mistral), wird bemessen wie jede andere Webanwendung: das Modell läuft beim Anbieter, und Ihr Server wartet auf die Antwort. Erst die Ausführung des Modells auf dem Server selbst verändert die Größenordnung.

Auf einem laufenden Server messen

Auf einem Server in Betrieb ersetzt die Messung die Schätzung. Drei Befehle zeigen, wo Sie stehen:

free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5

• free -h: lesen Sie die Spalte available, den Speicher, der tatsächlich für neue Programme verfügbar ist. Die Spalte free ist fast immer niedrig, und das ist normal: Linux füllt ungenutzten Speicher mit dem Datei-Cache (buff/cache) und gibt ihn frei, sobald ein Programm ihn braucht.
• ps aux --sort=-rss: die Prozesse nach belegtem Speicher sortiert (Spalte RSS, in Kilobyte). Hier sehen Sie, was jeder PHP- oder Node.js-Worker wiegt.
• vmstat 5 5: fünf Messungen im Abstand von fünf Sekunden. Werte ungleich null in den Spalten si und so, Messung für Messung, zeigen einen Server, der in den Swap auslagert: ihm fehlt Arbeitsspeicher.

Messen Sie zur geschäftigsten Tageszeit und während der gelegentlichen Aufgaben: Build, Backup, Import. Es zählt die Spitze.

Wenn der Arbeitsspeicher knapp wird

Ein Server ohne freien Speicher wird nicht allmählich langsamer. Wenn nichts mehr freizugeben ist, löst der Linux-Kernel den OOM-Killer aus (out of memory): er wählt einen Prozess, in der Regel den mit dem größten Speicherverbrauch, und beendet ihn sofort. Auf einem Anwendungsserver ist das oft die Datenbank.

Die Symptome: zeitweise Fehler 502 oder 503, ein Dienst, der ohne erkennbaren Grund neu startet, ein Build, der mit Killed abbricht. Die Logs bestätigen es:

journalctl -k | grep -i "out of memory"
systemctl status name-des-dienstes

In der Ausgabe von systemctl status kennzeichnet der Hinweis Failed with result 'oom-kill' einen Dienst, der aus Speichermangel beendet wurde.

Der Swap, sofern der Server einen hat, zögert diesen Moment hinaus, indem er den am wenigsten genutzten Speicher auf die Festplatte auslagert. Er ist ein Sicherheitsnetz, keine Kapazität: ein Server, der dauerhaft auf den Swap angewiesen ist, antwortet um ein Mehrfaches langsamer, selbst auf einer NVMe-SSD.

Die Abhilfen, von der einfachsten bis zur nachhaltigsten: die Zahl der Anwendungsprozesse senken (pm.max_children, Gunicorn-Worker), außerhalb des Servers bauen, den Speicher der Datenbank begrenzen, dann in die nächsthöhere Größe wechseln.

Die Größe wählen und vorausplanen

1. Listen Sie auf, was laufen wird: Webserver, Anwendung und Zahl ihrer Prozesse, Datenbank, Cache, geplante Jobs.
2. Addieren Sie mit der Tabelle der Bausteine, nehmen Sie die schwerste Spitze hinzu (oft den Build) und dann 25 % Reserve.
3. Wählen Sie die Größe, die diese Summe abdeckt. Zwischen zwei benachbarten Größen genügt die kleinere, sofern der Wechsel in die nächsthöhere ohne Neuinstallation möglich ist.
4. Messen Sie nach dem Livegang, zur Tagesspitze, und dann bei jedem Wachstumsschritt der Anwendung.

Neben dem Arbeitsspeicher zählen weitere Ressourcen: der Prozessor für alles, was rechnet (Build, Bildverarbeitung, Ausführung eines KI-Modells), die Festplatte für die Datenbank und die Dateien. Bei einer Webanwendung ist es dennoch fast immer der Arbeitsspeicher, der die Größe bestimmt.