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, jeder Preis enthält ein wöchentliches Backup. 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
Der Preis jedes Presets enthält ein wöchentliches 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. Um den RAM eine ganze Woche lang zu messen und eine passende Größe zu erhalten, nutzen Sie das Skript ramuse.py aus den tatsächlichen RAM-Bedarf in der DRAM-Knappheit 2026 messen.
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
stist CPU-Zeit, die der Host genommen hat. - free - lesen Sie die Spalte
available, nichtfree. - vmstat - Werte ungleich null bei
siundsobedeuten Swapping. - iostat - hohes
%utilund wachsendesawaitzeigen, dass die Disk der Engpass ist.
Für eine ganze Anwendung statt einer einzelnen Last folgen Sie dem durchgerechneten Beispiel in SaaS-Cloud-Server dimensionieren: Speicherbudget je Container, k6-Lasttest und ein druckbares Arbeitsblatt.
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.
