Ratgeber

Überbuchung bei vServern: erkennen und vermeiden

Wenn dein vServer ruckelt, obwohl die CPU-Anzeige entspannt aussieht, steckt oft Überbuchung dahinter: Der Anbieter verkauft mehr virtuelle Ressourcen, als der physische Host tatsächlich besitzt. Dieser Ratgeber erklärt, wie Überbuchung von vCPU und RAM funktioniert, wie du sie über die CPU-Steal-Time erkennst und warum ein Cloud-Server ohne Überbuchung planbar schnell bleibt.

Cloud-Server ohne Überbuchung

Überbuchung — im Englischen Overcommitment oder Overprovisioning — heißt, dass ein Hosting-Anbieter mehr virtuelle Ressourcen verkauft, als der physische Host besitzt. Auf einer Maschine mit 32 CPU-Kernen laufen dann nicht 32, sondern 100 oder mehr vCPUs verteilt auf viele Kundenserver. Solange nicht alle gleichzeitig Last erzeugen, geht die Rechnung auf. Sobald aber mehrere Nachbarn gleichzeitig rechnen, konkurrieren sie um dieselben physischen Kerne — und dein vServer wartet.

Was Überbuchung genau bedeutet

Anbieter überbuchen aus wirtschaftlichen Gründen: Die meisten vServer laufen die meiste Zeit im Leerlauf, also lässt sich dieselbe Hardware mehrfach verkaufen. Entscheidend ist das Verhältnis. Ein moderates Overcommitment fällt kaum auf, ein aggressives sorgt dafür, dass die zugesagten Ressourcen unter Last regelmäßig nicht verfügbar sind. Das Gegenmodell sind fest reservierte oder dedizierte Ressourcen: Was dir zugesagt wird, gehört auch dir — jederzeit.

vCPU- und RAM-Überbuchung im Vergleich

Überbucht wird nicht nur die CPU. Vier Ressourcen sind betroffen, mit sehr unterschiedlichen Folgen:

  • vCPU-Überbuchung: Mehr zugewiesene vCPUs als physische Threads. Der Hypervisor verteilt Rechenzeit im Zeitschlitz-Verfahren — bei Andrang muss deine VM auf freie Takte warten.
  • RAM-Überbuchung: Mehr zugesagter Arbeitsspeicher als physisch verbaut, abgefangen über Techniken wie Memory Ballooning, KSM oder Swapping. Reicht der echte RAM nicht, wird auf die Platte ausgelagert — Größenordnungen langsamer.
  • Storage-Überbuchung (Thin Provisioning): Mehr zugesagter Speicher als real vorhanden. Unkritisch, solange nicht alle Kunden ihn gleichzeitig füllen.
  • Netzwerk-Überbuchung: Ein Uplink, den sich viele teilen. Erst unter Last als Einbruch bei Durchsatz und Latenz spürbar.

Warum Überbuchung die Performance killt

Das Tückische an Überbuchung ist, dass Benchmarks im Leerlauf gut aussehen. Erst wenn die „lauten Nachbarn“ gleichzeitig Last erzeugen, bricht die Leistung ein — und zwar unvorhersehbar. Für eine Datenbank bedeutet das schwankende Query-Zeiten, für einen Webshop höhere Antwortzeiten zur Stoßzeit, für einen Build-Server längere Pipelines. Am schmerzhaftesten ist RAM-Überbuchung: Sobald ausgelagert wird, fällt die Performance nicht linear, sondern schlagartig ab.

Überbuchung erkennen: CPU-Steal-Time

Der aussagekräftigste Indikator ist die CPU-Steal-Time (Kennzeichen `%st`). Sie misst den Anteil der Zeit, in der deine virtuelle CPU rechnen wollte, aber warten musste, weil der Hypervisor die physischen Kerne anderen VMs zugeteilt hat. Du siehst sie in `top`, `vmstat` oder detaillierter mit `mpstat -P ALL 1`. Ein dauerhaft erhöhter Wert ist das deutlichste Zeichen für einen überbuchten Host.

CPU-Steal-Time einordnen (Richtwerte, keine gemessenen Benchmarks)
CPU-Steal-TimeBedeutungHandlung
Nahe 0 %Kein Ressourcenkonflikt — die vCPU steht dir zur VerfügungAlles gut
Dauerhaft niedrig einstelligLeichte Konkurrenz durch Nachbar-VMsBeobachten
Dauerhaft zweistelligDer Host ist überbucht, andere VMs entziehen dir TakteAnbieterwechsel prüfen
  • Swap-Aktivität: Hohe `si`/`so`-Werte in `vmstat` deuten auf RAM-Knappheit oder RAM-Überbuchung hin.
  • Load-Average dauerhaft über der vCPU-Zahl bei nur mäßiger eigener Last.
  • Derselbe Benchmark liefert zu verschiedenen Tageszeiten deutlich unterschiedliche Ergebnisse.

Häufig gestellte Fragen