CPU Overcommitment bremst Virtual Server aus, weil Hypervisor mehr vCPUs zuteilt, als physische Kerne vorhanden sind, und dadurch Wartezeiten entstehen. Ich zeige die Ursachen, echte Messwerte wie CPU Ready Time und konkrete Stellschrauben, mit denen ich VPS Performance stabil halte.
Zentrale Punkte
Bevor ich tiefer einsteige, ordne ich die wichtigsten Aspekte ein und grenze typische Missverständnisse ab. Viele Betreiber verwechseln hohe Auslastung mit Effizienz, obwohl Warteschlangen die Antwortzeiten prägen. Scheduler-Details entscheiden, ob Anwendungen flüssig laufen oder stocken. Ich fasse die Kernthemen zusammen, auf die ich in den folgenden Kapiteln aufbaue. Die Liste dient als kompakte Referenz für schnelle Entscheidungen.
- Scheduler und Time-Slicing bestimmen, wie vCPUs an die Reihe kommen.
- CPU Ready zeigt Wartezeit an und warnt früh vor Engpässen.
- SMP-Gäste (mehrere vCPUs) verschärfen Overhead und Latenz.
- Rightsizing und Monitoring halten Lastspitzen beherrschbar.
- Providerwahl ohne Überbuchung sichert konstante Leistung.
Was bedeutet CPU Overcommitment technisch?
Overcommit heißt, ich weise mehr virtuelle Kerne zu, als der Host physisch besitzt, und verlasse mich auf den Hypervisor-Scheduler. KVM oder VMware teilen Rechenzeit über Time-Slicing zu, was bei geringer Last unauffällig wirkt und scheinbar hohe Dichte ermöglicht. Unter paralleler Last steigen jedoch Wartezeiten, weil mehrere vCPUs zeitgleich Rechenzeit verlangen und der Scheduler sie nacheinander einplanen muss. Red Hat warnt, dass besonders SMP-VMs mit vielen vCPUs stark verlieren, sobald die Summe der vCPUs die physischen Kerne deutlich übersteigt [1]. VMware-Experten quantifizieren das über CPU Ready Time: 1000 ms Wartezeit pro vCPU entsprechen rund 5% Leistungsverlust, kumulativ pro Kern [3].
Warum Virtual Server ausgebremst werden
Warteschlangen sind der Hauptgrund, warum Virtual Server bei Überbuchung langsamer werden, obwohl CPU-Nutzung hoch aussieht. Eine vCPU darf erst laufen, wenn ein physischer Kern frei ist; bis dahin steigt CPU Ready und die Anwendung wartet. Bei mehreren VMs mit parallelen Peaks verschärft sich der Effekt, weil alle „Ready-to-Run“ stehen und der Scheduler nur in Zeitscheiben arbeiten kann. Vor allem latenzkritische Workloads wie Datenbanken, APIs oder Shop-Backends reagieren empfindlich, da jeder zusätzliche Kontextwechsel und jede Verzögerung Ketteneffekte auslöst. Ich beobachte dann Timeouts, unruhige Antwortzeiten und eine steigende Varianz, die Nutzer spürbar irritiert.
Messgrößen: CPU Ready, Steal & Co.
Indikatoren wie CPU Ready, Co-Stop und Steal Time zeigen mir früh, ob Overcommitment meine VM trifft. CPU Ready in Hypervisor-Metriken sollte im Schnitt deutlich unter 5% bleiben; steigt der Wert auf zweistellige Prozentzahlen, bricht Durchsatz spürbar ein [3]. Co-Stop signalisiert, dass SMP-VMs nicht gleichzeitig eingeplant werden können, was Multi-Threading ausbremst. In Linux-Gästen lese ich Steal Time, die anzeigt, wie viel Zeit der Host meiner VM entzieht; Hintergründe und Tuning habe ich hier zugänglich erklärt: CPU Steal Time. Wer diese drei Signale kombiniert, erkennt Engpässe rechtzeitig und verhindert, dass sich Latenzprobleme bis zur Anwendung durchfressen.
Realbeispiel: Wenn 5:1 das Limit sprengt
Praxis schlägt Theorie, sobald reale Workloads mischen: Ein Host mit 4 physischen Kernen und 5 VMs à 4 vCPUs wirkt im Leerlauf unproblematisch, zeigt aber unter Last massive Wartezeiten. Startet eine VM Bildverarbeitung oder Backups, priorisiert der Scheduler zwar, doch die restlichen VMs sammeln CPU-Ready-Werte von über 2000 ms an, was etwa 10% Leistungsverlust pro Kern bedeutet [3]. In einem dokumentierten SQL-Server-Test fiel der Durchsatz bei aktiviertem Hintergrundbetrieb von 25.200 Transaktionen pro Minute auf weniger als die Hälfte [3]. Auch I/O wird indirekt langsamer, weil vCPUs während Blockgerät-Zugriffen preempted werden und die Pipelines ins Stocken geraten. Ich erlebe dann eine Mischung aus hohen Spitzen, langen Tails und unerwarteten Jitter in Antwortzeiten.
Besondere Risiken bei SMP-Gästen
SMP-VMs mit vielen vCPUs benötigen koordinierte Slots auf mehreren physischen Kernen, was Scheduling-Aufwand und Wartezeiten erhöht. Je mehr vCPUs eine einzelne VM hat, desto öfter wartet sie darauf, dass alle benötigten Zeitscheiben zusammenkommen. Red Hat rät deshalb, mehrere kleinere VMs mit wenigen vCPUs zu bevorzugen, statt einzelne „Breitspur“-Gäste zu fahren [1]. Ein Overcommit-Ratio von 10:1 gilt als grober Höchstwert; ich halte in produktiven Umgebungen deutlich weniger für sinnvoll, besonders bei dauerlastigen Services [1]. Wer Latenz als oberste Priorität setzt, begrenzt vCPUs pro VM und optimiert Threads so, dass sie mit weniger Kerngrundlast auskommen.
Webhosting-Praxis: Auswirkungen auf Websites
Websites auf überbuchten Hosts reagieren mit längeren Ladezeiten, instabiler Time to First Byte und schlechten Core Web Vitals. Suchmaschinen stufen langsame Seiten ab, Besucher springen schneller ab, und Conversion-Ketten reißen an unscheinbaren Mikrodelays [2]. In Shared-Umgebungen kennen viele den „Noisy Neighbor“; auf VPS mit Overcommitment passiert das subtiler, weil nominell mehr vCPUs zugewiesen sind. Ich kläre daher bei Traffic-Peaks immer zuerst, ob Ready- und Steal-Werte hochgehen, statt blind am Webserver zu schrauben. Wer Kosten drücken will, sollte sich die Risiken von günstigem Webhosting bewusst machen und klare Limits gegen Überbuchung einfordern [2].
Overcommitment vs. Bare Metal
Vergleich zeigt: Bare Metal liefert planbare Latenzen und linearen Durchsatz, während überbuchte Virtualisierung unter Last unruhig wird. Für latenzsensible Workloads wie Datenbanken, Queues, Observability-Stacks und Realtime-APIs zahlt sich Dedikation schnell aus. Ich bevorzuge dedizierte Kerne oder Bare Metal, sobald CPU Ready auffällig wird oder SMP-Gäste ins Stocken geraten. Wer Flexibilität braucht, kann mit Reserved-CPU-Instanzen oder Host-Gruppen ohne Overcommit eine Brücke bauen. Einen strukturierten Blick auf Optionen bietet der Vergleich Bare Metal Hosting, der Stärken und Kompromisse knapp gegenüberstellt.
Rechte Dimensionierung: Wie viele vCPUs sind sinnvoll?
Rightsizing beginnt mit dem realen Bedarf: Ich messe CPU, Run Queue, Disk- und Net-IO sowie Lock-Wait-Muster über mehrere Tagesprofile. Zeigen Messwerte einen Peak-Thread-Pool von vier, vergebe ich anfangs zwei bis vier vCPUs und erhöhe erst, wenn Ready und Co-Stop unauffällig bleiben. Die Faustregel „maximal 10 vCPUs pro physischem Kern“ ist eine Deckelung, kein Zielwert; produktiv plane ich konservativer [1]. Große VMs mit vielen vCPUs wirken attraktiv, vergrößern aber Koordinationsaufwand und Latenzschwankungen. Kleine, sauber geschnittene VMs skaliere ich horizontal und halte damit Warteschlangen kurz und effizient.
Überwachung und Alerts: Was ich einstelle
Monitoring macht Overcommitment sichtbar, bevor Nutzer es merken, deshalb setze ich klare Grenzwerte. CPU Ready im 1-Minuten-Mittel sollte idealerweise unter 5% pro vCPU bleiben, Co-Stop dauerhaft gegen null tendieren und Steal Time nur kurzzeitig spürbar sein [3]. Bei Überschreitung skaliere ich horizontal, parke Hintergrundjobs abseits produktiver VMs oder verschiebe Gäste auf Hosts mit Luft. Alerts trenne ich nach Schwere: Sofortalarm für starke Anstiege, Ticket für wiederkehrende moderate Ausschläge. So verhindere ich Alert-Müdigkeit und greife gezielt ein, wenn Latenz wirklich geschäftskritisch wird.
Provider-Auswahl: Worauf ich achte
Auswahl eines VPS-Anbieters entscheidet über Konstanz unter Last, daher prüfe ich Offerten kritisch auf Überbuchung. Transparente Angaben zu vCPU-zu-Core-Verhältnissen, klare Zusagen zu dedizierten Kernen und konsistente Benchmarks sind Pflicht. In einem 2025er Vergleich schnitten Angebote mit NVMe-Storage, moderner CPU-Generation und ohne CPU-Überbuchung am besten ab, mit stabiler Uptime und gleichmäßiger Latenz [6]. Preis allein führt häufig zu verstecktem Overselling, was in produktiven Szenarien teurer wird als ehrliche Ressourcen. Die folgende Tabelle zeigt Kernparameter, die ich nebeneinanderlege, um Engstellen zu vermeiden.
| Anbieter | vCPUs | RAM | Speicher | Uptime | Preis/Monat | Testsieger |
|---|---|---|---|---|---|---|
| webhoster.de | 4–32 | 8–128 GB | NVMe | 99,99% | ab 1 € | Ja |
| Hetzner | 2–16 | 4–64 GB | SSD | 99,9% | ab 3 € | Nein |
| Contabo | 4–24 | 8–96 GB | SSD | 99,8% | ab 5 € | Nein |
Kapazitätsplanung: Sobald Lastspitzen drohen
Planung beginne ich mit Workload-Profilen: Spitzenzeiten, Burst-Dauer, Parallelität und Latenzbudgets. Bei steigender Grundlast ziehe ich zuerst vertikal an, solange Ready-Time stabil bleibt; kippt die Kurve, splitte ich Dienste auf mehrere kleinere VMs. Hintergrundjobs trenne ich konsequent vom Frontend, damit Bestellvorgänge oder Checkout nicht mit Reports konkurrieren. Auto-Scaling hilft, doch ohne Obergrenzen und klare Metriken produziert es teure Fehlschaltungen. Besser wirkt eine Stufenlogik: Schwellen definieren, Maßnahmen testen, Ergebnis messen und Schwellen danach feinjustieren.
Was eine vCPU wirklich ist: SMT und Frequenzeffekte
vCPU bedeutet meist ein Hardware-Thread (SMT/Hyper-Threading), nicht zwingend ein voller physischer Kern. Zwei vCPUs können auf einem Kern liegen und teilen sich Decoder, Caches und Ausführungseinheiten. Unter reiner Integer- oder Memory-Last bringt SMT spürbare Vorteile, bei saturierten Pipelines konkurrieren Threads jedoch direkt um Ressourcen. Das erklärt, warum Hosts mit „vielen vCPUs“ unter Last nicht linear skalieren: Der Scheduler kann zwar Slots verteilen, aber nicht mehr physische Recheneinheiten erzeugen. Zusätzlich wirken sich Power- und Turbo-Policies aus. Wenn viele Threads parallel laufen, sinken Turbo-Frequenzen und die Single-Thread-Performance fällt. Für Latenz-Klassen ziehe ich daher dedizierte Kerne, SMT-Off oder CPU-Pinning in Erwägung, damit Threads vorhersehbare Leistungsfenster erhalten.
NUMA-Bewusstsein: Speicher-Lokalität entscheidet
NUMA trennt moderne Mehrsocket-Hosts in Knoten mit eigener Speicheranbindung. Große SMP-VMs, die über mehrere NUMA-Nodes strecken, zahlen mit höherer Speicherlatenz, Remote-Zugriffen und zusätzlicher Koordination. Ich richte vCPU- und RAM-Zuweisung so aus, dass eine VM bevorzugt in einen Node passt. Praktisch bedeutet das: Weniger vCPUs pro VM, dafür horizontale Skalierung. Im Gast vermeide ich übergroße, global synchronisierte Thread-Pools und setze auf Sharding pro Instanz. Wer Datenbanken virtualisiert, profitiert doppelt: Bessere Cache-Hitrate und weniger cross-node Traffic. NUMA-Fehlplazierung tarnt sich oft als „CPU-Probleme“, sichtbar wird sie aber an steigender Memory-Latency und Read-Misses, während CPU Ready nur moderat wirkt.
Burst- und Credit-Modelle: verdeckte Limits
Burst-Instanzen mit CPU-Credits liefern im Leerlauf gute Werte, drosseln jedoch bei Credit-Leere, obwohl CPU Ready unauffällig bleibt. Für Betreiber ist das tückisch, weil Latenzspitzen „aus dem Nichts“ auftreten. Ich prüfe daher, ob ein Tarif Credits oder „Fair-Share“-Regeln nutzt und ob Mindestleistung garantiert ist. Workloads mit periodischen Peaks (Cron, ETL, Rechnungsbatch) fressen Credits schnell auf und fallen danach in eine harte Bremse. Die Lösung: Entweder auf reservierte Kerne wechseln oder Bursts entkoppeln – etwa durch ein separates Batch-Profil mit eigenem Zeitfenster, damit produktive APIs nicht in die Drossel laufen. Overcommitment plus Credit-Throttle ist die ungünstigste Kombination für planbare Reaktionszeiten.
Container auf dem VPS: doppeltes Scheduling vermeiden
Container-Orchestrierung in einer bereits überbuchten VM führt leicht zu „Double-Overcommit“. Der Host scheduler priorisiert VMs, der Gast scheduler Container – beide ohne Wissen über die reale Kernverfügbarkeit. Ich setze daher klare CPU-Quoten und nutze cpuset, um kritische Container an bestimmte vCPUs zu binden. Gleichzeitig halte ich die Summe der Container-Threads unter dem realistisch verfügbaren Budget der VM, nicht unter dem nominalen vCPU-Wert. Für Build- oder Batch-Container definiere ich niedrigere Shares, damit Frontend-Services Vorrang behalten. Wichtig: irqbalance und Netzwerk-Stack dürfen kritische vCPUs nicht mit Interrupt-Fluten überfahren; ich isoliere im Zweifel ein, zwei vCPUs für Netz- und Storage-Interrupts, um Latenzspitzen zu dämpfen.
Messpraxis: So lese ich die richtigen Zahlen
Im Hypervisor prüfe ich CPU Ready (gesamt und pro vCPU), Co-Stop und Run-Queue-Länge pro Host. Auf KVM korreliere ich domstats der VMs mit Host-Load und IRQ-Last. Im Gast beobachte ich %steal, %iowait, Run-Queue (r) und Kontextwechsel. Ein wiederkehrendes Muster ist: Hohe Run-Queue + steigende %steal + schwankende Latenz = Overcommitment. Bleibt %steal niedrig, aber L3-Misses und Syscalls steigen, deute ich eher auf Lock-Contention oder NUMA-Probleme. Ich zähle außerdem aktive Request-Threads und vergleiche sie mit vCPU-Anzahl: Wenn Web- oder Worker-Pools permanent über dem Kernbudget liegen, erzeuge ich selbst Warteschlangen. Besser ist es, Eingangsqueues zu begrenzen und abzuweisen, statt verzögert zu verarbeiten – das verbessert Nutzerwahrnehmung und stabilisiert Systeme.
Konkrete Tuning-Hebel im Gast und Host
Schnelle Gewinne erziele ich mit wenigen, zielgenauen Schritten: Im BIOS setze ich auf Performance-Profile, deaktiviere tiefe C-States und halte Frequenzskalierung konsistent. Auf dem Host stelle ich den CPU-Governor auf „performance“ und reduziere Störgeräusche durch Hintergrund-Dienste. In der VM senke ich vCPUs auf den real benötigten Wert, pinne kritische Prozesse (z. B. Datenbank-IO-Threads) an feste vCPUs und begrenze Thread-Pools der Applikation. Für Webserver und Runtimes gilt: worker_processes (Nginx), pm.max_children (PHP-FPM) oder JVM-Executor-Pools nicht größer wählen als das verfügbare Kerngesamtbudget abzüglich System-Overhead. Große Pages und konsistente Timer-Quellen reduzieren Scheduling-Overhead; gleichzeitig vermeide ich aggressives Overcommit bei RAM, damit nicht zusätzlich Swap-Latenzen in die Pipeline geraten.
Applikationsdesign: Backpressure statt Überfüllung
Backpressure ist die saubere Antwort auf knappe Kerne. Statt Request-Fluten in riesigen Queues zu puffern, limitiere ich parallel verarbeitete Aufträge auf die Kerne plus Reserve. Services signalisieren bei Spitzenauslastung „busy“ oder liefern degradierte, aber schnelle Antworten (z. B. kürzere Caches, weniger Details). Datenbanken bekommen kürzere Lock-Timeouts und schlankere Transaktionen; Search- und Analytics-Abfragen laufen zeitlich versetzt. In Microservice-Landschaften bremse ich an der Kante, nicht in der Tiefe: API-Gateways und Ingress-Limits verhindern, dass interne Abhängigkeiten kollabieren. Das Ergebnis sind geordnete Warteschlangen mit kurzen Tails – genau das, was unter Overcommitment die Nutzererfahrung rettet.
Live-Migration und Hintergrundlast: versteckte Stolpersteine
vMotion/Live-Migration oder Host-Wartungsfenster verursachen kurzfristig erhöhte Latenzen, auch wenn Overcommitment moderat ist. Während Speicher kopiert und CPU-Zustände synchronisiert werden, verschieben sich Zeitscheiben und IO-Pfade. Fällt das Ereignis mit Batch-Fenstern zusammen, kumulieren sich Verzögerungen. Ich plane Migrationsfenster außerhalb Peak-Zeiten und parke parallel laufende Jobs. Ebenso trenne ich Backup/Antivirus/Indexing strikt von Latenzpfaden – idealerweise auf eigene VMs mit niedriger Priorität. So verhindere ich, dass „gut gemeinte“ Wartungsvorgänge Performance-Messungen verfälschen oder Nutzerströme treffen.
Checkliste: In 15 Minuten zur klaren Diagnose
- Zeitraum wählen, Last reproduzieren (Loadtest oder Peakfenster).
- Hypervisor: CPU Ready pro vCPU, Co-Stop, Host-Run-Queue prüfen.
- Gast: %steal, %iowait, Run-Queue, Kontextwechsel, IRQ-Last messen.
- Thread- und Worker-Pools der Anwendung mit vCPU-Zahl abgleichen.
- Hintergrundjobs und Cron-Läufe identifizieren und verschieben.
- Test: vCPU-Zahl halbieren oder pinnen, Ready/Steal erneut messen.
- Wenn Werte fallen und Latenz glättet: Horizontal splitten, Limits fixieren.
- Wenn keine Besserung: Host/Plan wechseln, dedizierte Kerne prüfen.
10 typische Fehlannahmen, die Leistung kosten
Irrtümer sehe ich regelmäßig: Mehr vCPUs bedeuten nicht automatisch mehr Geschwindigkeit, wenn der Host bereits eng taktet. Ein hoher CPU-Wert in der VM belegt keinen vollen Kerneinsatz, solange Ready hoch ist und Steal steigt. Große SMP-VMs liefern nicht zwangsläufig bessere Parallelität, wenn Synchronisation und Locks dominieren. Priorisierungsfunktionen des Hypervisors heben physische Grenzen nicht auf; sie verschieben Verzögerungen nur. Und Datenbank- oder PHP-Tuning kaschiert Engpässe nur kurz, wenn der Scheduler das eigentliche Nadelöhr bleibt.
Konkrete Schritte: Von Symptomen zur Ursache
Vorgehen starte ich reproduzierbar: Zuerst Lastszenario definieren, dann CPU Ready, Co-Stop, Steal und IO-Wartezeiten im selben Zeitfenster mitschneiden. Zeigen Metriken typische Overcommit-Signaturen, reduziere ich vCPU-Zahl pro VM, verteile SMP-Workloads und verschiebe Hintergrundprozesse. Bleiben Werte hoch, ziehe ich die VM auf einen Host mit niedrigem Ratio oder reservierten Kernen um. Weicht erst dann die Latenz, sichere ich das neue Profil als Baseline und verankere Alarme auf Prozent- und Millisekundenwerten. So löse ich nicht Symptome, sondern adressiere die Ursache im Scheduling.
Kurz zusammengefasst
Zusammenfassung: CPU Overcommitment klingt effizient, erzeugt aber unter Last Warteschlangen, die Virtual Server bremsen. Messgrößen wie CPU Ready Time, Co-Stop und Steal Time zeigen das Problem klar an und liefern objektive Schwellen. Red Hat empfiehlt konservative Verhältnisse und kleinere VMs mit wenigen vCPUs, während Praxisdaten aus VMware-Umgebungen den Einfluss auf Durchsatz und Antwortzeiten belegen [1][3]. Für Websites und APIs drohen Ranking-Verluste, Absprünge und fehleranfällige Prozesse, wenn Latenz schwankt [2]. Ich setze daher auf Rightsizing, sauberes Monitoring, klare Schwellen und – wenn nötig – dedizierte Kerne oder Bare Metal, um VPS Performance verlässlich zu halten.
