Cloud-Server dimensionieren: Wie viel CPU, RAM und SSD?

Cloud-Server dimensionieren: Wie viel CPU, RAM und SSD?

Die Dimensionierung eines Cloud-Servers beginnt mit der Last, nicht mit der Hardware. Dieser Leitfaden nennt Startbereiche für vCPU, RAM und Speicher typischer Workloads, ordnet sie den Presets Small, Medium und Large auf der Seite DCXV Cloud-Server zu und zeigt, wie Sie das Ergebnis nach dem Deployment mit wenigen Shell-Befehlen prüfen. Alle Bereiche unten sind Schätzungen und Ausgangspunkte, keine Messwerte. Ihr Code, Ihr Traffic und Ihre Daten bestimmen die echten Zahlen.

Mit der Last beginnen

Notieren Sie vier Fakten, bevor Sie einen Konfigurator öffnen: was läuft (Webserver, Datenbank, Windows-Anwendung), wie viele Nutzer oder Anfragen in der verkehrsreichsten Stunde eintreffen, wie viele Daten heute vorhanden sind und wie schnell sie wachsen.

Finden Sie dann die Ressource, die zuerst knapp wird. Ein PHP-Shop geht meist eher der RAM aus als die CPU. Ein Build-Server braucht CPU. Eine Datenbank braucht erst RAM, dann Plattengeschwindigkeit. Dimensionieren Sie auf diesen Engpass, der Rest folgt.

Startbereiche nach Workload

Die Presets: Small hat 2 vCPU, 4 GB RAM, 40 GB NVMe ab EUR 15.00/Monat. Medium hat 4 vCPU, 8 GB RAM, 80 GB NVMe ab EUR 18.43/Monat. Large hat 8 vCPU, 16 GB RAM, 160 GB NVMe ab EUR 36.88/Monat. Preise geprüft 2026-10, je ein Backup inklusive. Lesen Sie vor dem Vergleich, was den Preis bestimmt.

Workload	Startbereich (Schätzung)	Nächstes Preset
Dev/Test, VPN, Monitoring, Hilfsdienste	1-2 vCPU, 1-4 GB RAM, 20-40 GB Disk	Small
Kleine Website oder Blog, wenig Traffic	2 vCPU, 2-4 GB RAM, 20-40 GB Disk	Small
Onlineshop, API oder SaaS-MVP	2-4 vCPU, 4-8 GB RAM, 40-80 GB Disk	Medium
App mit eigener Datenbank	4-8 vCPU, 8-16 GB RAM, 80-160 GB Disk	Medium oder Large
Windows/RDP-Geschäftsanwendung	Zuerst die Herstellerformel. M.E.Doc Terminal: CPU = 4 + Nutzer, RAM = Nutzer x 2 GB + 4 GB	Large bis 4 Nutzer, darüber individuell

Annahmen: Linux, eine Hauptanwendung, normaler Traffic mit gelegentlichen Spitzen, keine GPU-Arbeit, keine schweren Batch-Jobs. Eine meist leere Dev-Maschine braucht weniger. Ein unoptimierter Plugin-Stapel braucht mehr. Für die Windows-Zeile geht die Herstellerformel jeder Tabelle vor: Sie ist eine Anforderung, keine Schätzung, und hängt vom Deployment-Typ ab, lesen Sie also die aktuelle Seite des Herstellers. Liegen Ihre Zahlen zwischen den Presets oder über Large, stellen Sie im Rechner auf der Cloud-Server-Seite eine eigene Konfiguration zusammen.

Ein durchgerechnetes RAM-Budget für einen kleinen Shop

Hier ein Beispielbudget für einen Onlineshop auf einem Server. Die Zahlen sind Annahmen, keine Messwerte.

• Betriebssystem und Dienste - 0.5 GB.
• PHP-FPM - 10 Worker x 100 MB = 1 GB.
• Datenbank-Pufferpool - 2 GB.
• Redis-Cache - 0.5 GB.
• Dateicache und Spitzen - 1 GB.

Die Summe liegt bei etwa 5 GB. Ein Server mit 4 GB würde unter Last swappen. Ein Server mit 8 GB behält rund 3 GB, etwa ein Drittel, frei. Ersetzen Sie jede Zeile durch eigene Zahlen, sobald der Shop läuft: Die Befehle unten zeigen sie.

Reserve, Betriebssystem und Speicher

• CPU - Ziel ist eine Dauerlast unter etwa 70% in der stärksten Stunde, damit eine Spitze keine Anfragen aufstaut.
• RAM - halten Sie 20-25% verfügbar. Dauerndes Swappen heißt: Der Server ist zu klein.
• Disk - bleiben Sie unter 80% Füllstand. Datenbanken, Logs und Updates wachsen schneller als geplant.
• Betriebssystem - ein minimales Linux kommt mit einigen hundert MB aus. Windows Server mit Desktop braucht einige GB, bevor Ihre Anwendung startet (Schätzung).
• Plattengeschwindigkeit - Kapazität ist nicht Tempo. Eine ausgelastete Datenbank achtet auf Latenz, also messen Sie sie.

Backup-Kapazität ist kein Produktivspeicher

Jedes Preset enthält ein Backup. Es ist eine Sicherungskopie der Server-Disk, kein zusätzlicher Platz für Ihre Dateien. Rechnen Sie es bei der Disk-Größe nicht mit und planen Sie nicht, Archive, Medien oder Dumps "im Backup" zu halten. Produktive Daten liegen auf der Server-Disk, dimensionieren Sie diese also für Daten, Wachstum und Reserve. Legen Sie vor einer riskanten Änderung einen Snapshot an: siehe Cloud-VM-Snapshots.

Nach dem Deployment messen

Messen Sie in einer normalen Stoßzeit und noch einmal bei einer Spitze. Unter Debian oder Ubuntu stammt iostat aus dem Paket sysstat.

top -b -n 1 | head -n 15
free -h
vmstat 5 5
df -h
sudo apt install sysstat
iostat -xz 5 3
ps -eo pid,comm,%mem,%cpu --sort=-%mem \
  | head -n 8
sudo du -xh --max-depth=1 /var \
  | sort -h \
  | tail -n 8

So lesen Sie die Ausgabe:

• top - vergleichen Sie die Load Average mit der vCPU-Zahl. Eine dauerhaft höhere Load bedeutet CPU-Druck. Der Wert st ist CPU-Zeit, die der Host genommen hat.
• free - lesen Sie die Spalte available, nicht free.
• vmstat - Werte ungleich null bei si und so bedeuten Swapping.
• iostat - hohes %util und wachsendes await zeigen, dass die Disk der Engpass ist.

Auswählen und prüfen

Nehmen Sie das nächstgelegene Preset aus der Tabelle und betreiben Sie es unter echter Last. Ein kurzer Test ist der ehrliche Weg, eine Schätzung zu prüfen: siehe die Testphase-Checkliste. Fragen Sie per E-Mail an sales@dcxv.com nach einer kurzen Testphase; sie liegt im Ermessen von DCXV und ist nicht garantiert. Weichen Ihre Messwerte von der Tabelle ab, vertrauen Sie den Messwerten. Unsicher bei Ihren Zahlen? Senden Sie Ihre Anforderungen an sales@dcxv.com, ein Ingenieur prüft sie, oder öffnen Sie die Cloud-Server-Seite und wählen Sie ein Preset.