„Der Server ist langsam, verdoppeln wir den RAM“ ist der teuerste Reflex im Hosting. Manchmal stimmt er. Oft wartet die Maschine aber auf die Festplatte, oder die CPU ist am Anschlag, und der neue Speicher liegt untätig herum, während sich die Rechnung verdoppelt.
Bevor wir also darüber reden, wer 64 GB braucht, klären wir, was Ihnen wirklich fehlt. Wenn Sie nur typische Speicherzahlen pro Workload suchen, finden Sie sie in unserem früheren Leitfaden Wie viel RAM braucht ein VPS, samt Formel für Sprachmodelle. Hier geht es um die Diagnose: RAM, Festplatte oder CPU.
Drei Befehle, zwei Minuten
Führen Sie sie auf dem langsamen Server aus, während er langsam ist, nicht um vier Uhr morgens, wenn nichts los ist:
free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
So lesen Sie sie ohne Lehrbuch.
free -m. Ignorieren Sie die Spalte free; Linux füllt freien Speicher absichtlich mit Festplatten-Cache. Schauen Sie auf available. Sind es auf einer 2-GB-Maschine nur ein paar hundert Megabyte und wächst used beim Swap ständig, wird der Speicher knapp.
vmstat 1 10. Vier Spalten erzählen den Großteil der Geschichte:
| Spalte | Bedeutung | Hinweis auf |
|---|---|---|
si / so | ein- und ausgelagerte Seiten pro Sekunde | RAM |
wa | % der Zeit, in der die CPU auf die Festplatte wartet | Festplatte |
us + sy | % der Zeit, in der die CPU arbeitet | CPU |
st | % der Zeit, in der der Hypervisor Ihre CPU jemand anderem gab | CPU (vCPU wird mit anderen geteilt) |
Ein paar Werte ungleich null bei si/so ab und zu sind normal. Das echte Signal ist ständiges Swappen, Sekunde für Sekunde.
/proc/pressure/*. Der ehrlichste der drei. Jede Datei zeigt den Anteil der Zeit, in der Aufgaben auf diese Ressource gewartet haben. some avg60=25.00 bei memory heißt: In der letzten Minute hat ein Viertel der Zeit irgendetwas auf Speicher gewartet. Die Datei mit den größten Zahlen zeigt Ihren Engpass.
Wenn es die Festplatte ist
Hohes wa, hoher io-Druck, wenig Swapping. Die übliche Ursache ist eine Datenbank oder eine log-lastige Anwendung, die mehr liest, als in den Cache passt.
Hier die Wendung: Mehr RAM kann das beheben, weil Linux dann mehr von der Festplatte cacht. Ist Ihre Datenbank 6 GB groß und der heiße Teil 3 GB, kann der Sprung von 2 auf 8 GB Speicher das Festplattenproblem verschwinden lassen. Ist die Datenbank aber 300 GB groß und berührt jede Abfrage einen anderen Teil, cacht sie keine vernünftige RAM-Menge. Dann helfen bessere Indizes, kleinere Abfragen oder ein anderes Datenlayout. Alle Tarife hier laufen auf NVMe, die Festplatte selbst ist also selten das Langsame. Das Zugriffsmuster meistens schon.
Wenn es die CPU ist
Hohes us+sy, cpu-Druck, kein Swapping, wenig Warten auf die Festplatte. Komprimierung, Builds, Videokodierung, Bildverarbeitung, Krypto-Mathematik. Mehr Speicher hilft hier überhaupt nicht.
Behalten Sie auch st im Blick. Auf einem VPS ist eine vCPU ein Anteil an einem physischen Kern, nicht der ganze Kern: Die Zahl im Tarif ist eine Obergrenze für Lastspitzen, und dauerhafte Volllast kann gedrosselt werden, damit es für alle auf der Maschine fair bleibt. Braucht Ihr Job stundenlang alle Kerne bei 100 %, ist das eine Frage des Workloads, und das sagen wir lieber jetzt als nach dem Kauf eines größeren Tarifs.
Wenn es wirklich der RAM ist
Ständiges Swappen, steigender Speicherdruck, der OOM-Killer in dmesg. Jetzt lautet die Frage: wie viel.
2 GB reichen, oft jahrelang, für: einen oder ein paar Bots, eine kleine API, ein VPN, eine statische Website hinter Nginx, ein paar Cron-Scraper, einen Monitoring-Agenten. Micro bietet 2 vCPU, 2 GB und 25 GB für $5 im Monat mit NAT oder $10 mit eigener IPv4.
4–8 GB sind die bequeme Mitte: eine Web-App samt Datenbank, ein kleiner Suchindex, Headless-Browser-Automatisierung, ein paar Agenten nebeneinander.
32–64 GB sind für Daten, die im Speicher leben müssen:
- eine Datenbank, deren Working Set Dutzende Gigabyte groß ist, damit der Cache die heißen Daten wirklich hält;
- ein großer In-Memory-Cache oder eine Queue, die nicht auf die Festplatte ausweichen kann, ohne alles zu bremsen;
- ein Vektorindex für die Suche über Millionen von Chunks (echte Zahlen in Self-hosted RAG im großen Maßstab);
- CPU-Inferenz eines mittelgroßen Sprachmodells, bei der die Gewichte in den RAM passen müssen;
- Konsolidierung: zehn Dienste, die früher auf zehn kleinen Servern liefen.
Genau dafür gibt es Pro-64: 12 vCPU, 64 GB RAM, 600 GB NVMe und eine dedizierte IPv4 für $70 im Monat. Die Stufen dazwischen sind Pro-32 für $40 und Pro-48 für $55; darüber Pro-80 für $90. Welche Standorte für die Pro-Tarife verfügbar sind, siehst du bei der Bestellung.
Wo eine große Maschine nicht passt
Drei Fälle, in denen 64 GB die falsche Antwort sind, selbst wenn Sie es sich leisten können.
GPU-Arbeit. Keiner dieser Tarife hat eine GPU. Braucht Ihr Modell eine für Training oder schnelle Inferenz, wird eine CPU-Maschine mit viel RAM es zwar ausführen, aber langsam, und Sie bezahlen für Geduld.
Dauerhafte Volllast-Jobs. Wie oben: vCPUs sind Burst-Kapazität. Zwölf davon rund um die Uhr bei 100 % sind nicht das, wofür ein VPS gebaut ist.
Und „für alle Fälle“. Zeigen die drei Befehle keinen Speicherdruck, sind die zusätzlichen 60 GB Cache für Dateien, die Sie nicht lesen. Fangen Sie kleiner an. Der Wechsel auf einen größeren Tarif desselben Netzwerktyps fügt vCPU, RAM und Festplatte direkt hinzu, mit einem Neustart, wie unter Tarif wechseln beschrieben. Verkleinern geht nicht direkt, deshalb hat ein zu großer Kauf echte Kosten: Zum Schrumpfen ziehen Sie auf einen neuen Server um, und einen VPS ohne Ausfallzeit umziehen ist eine Mühe, die Sie sich lieber sparen.
Wenn Sie Tarife verschiedener Anbieter vergleichen, erklärt VPS-Spezifikationen richtig lesen, was die Zahlen zu vCPU, Festplatte und Port wirklich versprechen.
Kommentare
Noch keine Kommentare. Sei der Erste.