Wie wird die Proxmox-CPU-Überbuchungsquote 2026 festgelegt?

Eine VM reagiert zu Spitzenzeiten träge, obwohl der Proxmox-Host viele vCPUs an die Gäste verteilt hat.
Schnellste Lösung: Legen Sie keine feste Proxmox-CPU-Überbuchungsquote zugrunde. Verteilen Sie vCPUs nach paralleler Last und beobachteter CPU-Wartezeit; reduzieren Sie unnötige Zuteilungen, bevor Sie zusätzliche Hostkapazität beschaffen.

Dieser Leitfaden richtet sich an Proxmox-Administratoren, die neue VMs einrichten und keine beliebige Faustregel übernehmen möchten.
MSPs und kleine VPS-Betreiber finden ein Verfahren, um Mehrmandantenlast und Spitzenzeiten zu bewerten.
Für IT-Teams zeigt er, wie Messwerte zwischen ungenutzter Reserve und tatsächlicher Konkurrenz unterscheiden helfen.

Proxmox-CPU-Überbuchungsquote: Kontingent ist keine Rechenzeit

Die Summe der zugewiesenen vCPUs sagt zunächst nur, welche virtuellen Prozessoren die Gäste verwenden dürfen. Sie ist keine Garantie, dass jede VM gleichzeitig die entsprechende physische Rechenleistung erhält. Der Host plant die Ausführung der virtuellen Prozessoren auf seine verfügbaren CPU-Ressourcen. Wenn mehrere Gäste zur selben Zeit rechnen wollen, müssen sie um diese Ressourcen konkurrieren.

Eine Quote kann deshalb nur ein Planungswert sein. Sie wird aussagekräftig, wenn sie zur tatsächlichen Parallelität der Arbeitslast passt. Für Entwicklungs- und Testsysteme mit wechselnder Aktivität kann eine höhere Zuteilung als die Zahl der gleichzeitig benötigten physischen Ressourcen vertretbar sein. Bei dauerhaft rechnenden Aufgaben ist dieselbe Annahme riskanter: Viele Gäste benötigen dann zur selben Zeit CPU-Rechenzeit.

Drei Größen sollten getrennt dokumentiert werden:

• Verfügbare Hostressourcen: Zahl der physischen CPU-Kerne und logischen Threads, wie sie das Hostsystem erkennt. Threads sind kein gleichwertiger Ersatz für physische Kerne und keine Garantie für eine bestimmte Gastleistung.
• Zugewiesene vCPUs: Summe der vCPU-Kontingente, die den aktiven VMs zugeteilt wurden. Ein hoher Gesamtwert ist allein noch kein Überlastungsnachweis.
• Gleichzeitige Nachfrage: Zahl und Art der Gäste, die in einem relevanten Zeitraum tatsächlich rechnen müssen. Diese Nachfrage ist nicht aus der Konfiguration abzulesen, sondern muss beobachtet werden.

Proxmox VE 9.2 wurde laut offizieller Versionsankündigung am 21. Mai 2026 veröffentlicht. Daraus folgt weder eine empfohlene Überbuchungsquote noch eine bestimmte Kapazität pro Server. Die Versionsnummer ist für die Dokumentation und Prüfung der eingesetzten Funktionen relevant, nicht als CPU-Leistungsversprechen. Einstellungen und Begriffe sollten mit dem Proxmox-VE-9.x-Verwaltungshandbuch abgeglichen werden.

Lastprofile statt einer Quote für alle Gäste

Ein Mittelwert über einen ruhigen Zeitraum verdeckt kurze, aber geschäftskritische Spitzen. Ein interner Dienst kann die meiste Zeit kaum CPU benötigen und bei einem Berichtslauf mehrere Gäste gleichzeitig aktivieren. Eine Entwicklungsumgebung kann viele VMs enthalten, obwohl nur ein Teil parallel kompiliert. Eine dauerhaft rechnende Anwendung dagegen benötigt auch außerhalb einzelner Spitzen konstant CPU-Zeit.

Erstellen Sie für jede VM-Gruppe ein einfaches Lastprofil:

• Entwicklung und Test: Halten Sie fest, wann Builds, Tests oder andere parallele Aufgaben laufen. Prüfen Sie, ob die Last gleichzeitig startet oder über den Zeitraum verteilt ist.
• Interne Dienste: Erfassen Sie wiederkehrende Aktivitätsspitzen, etwa geplante Wartungsarbeiten oder gebündelte Hintergrundaufgaben. Bewerten Sie deren Auswirkungen auf andere Gäste.
• Dauerhafte Berechnungen: Behandeln Sie die CPU-Nachfrage als kontinuierlich, solange Messungen keine regelmäßigen Ruhephasen belegen. Hier ist eine rechnerische Überbuchung besonders sorgfältig zu prüfen.
• Mehrmandantenbetrieb: Ordnen Sie Dienste nach ihrer Bedeutung und ihren zugesagten Reaktionszeiten. Ein Gast mit geringer Priorität sollte nicht unbemerkt die gesamte verfügbare Rechenzeit beanspruchen.

Für eine belastbare Einschätzung werden keine erfundenen Parallelitätswerte benötigt. Beobachten Sie die VM-Gruppe während repräsentativer Betriebszeiten und notieren Sie, welche Gäste gleichzeitig aktiv waren. Vergleichen Sie einen ruhigen Zeitraum mit dem erwarteten Spitzenzeitraum. Wenn die Messung eine saisonale, monatliche oder geplante Spitze nicht umfasst, ist sie keine vollständige Grundlage für eine Kapazitätsentscheidung.

vCPU-Größe und Scheduler-Einstellungen getrennt bewerten

Mehr vCPUs für jede VM sind nicht automatisch besser. Ein Gast mit großem vCPU-Kontingent kann mehr virtuelle Prozessoren bereitstellen, als seine Anwendung tatsächlich parallel nutzt. Umgekehrt kann eine parallelisierte Aufgabe von mehreren verfügbaren vCPUs profitieren. Entscheidend sind Anwendung, Gastbetriebssystem und zeitgleiche Nachfrage.

Bewerten Sie deshalb zuerst die konkrete Aufgabe der VM:

• Benötigt die Anwendung mehrere gleichzeitig arbeitende Prozesse oder überwiegend einzelne Rechenabläufe?
• Tritt die hohe Nachfrage dauerhaft oder nur während klar abgegrenzter Aufgaben auf?
• Gibt es andere VMs mit höherer Priorität, die zur gleichen Zeit CPU-Zeit benötigen?
• Ist die VM-Auslastung niedrig, während die Anwendung trotzdem langsam ist? Dann können Speicher, Datenträger oder Netzwerk die Ursache sein.

Drei Einstellungen haben unterschiedliche Zwecke und sollten nicht verwechselt werden:

• vCPU-Zahl: Legt fest, wie viele virtuelle Prozessoren einer VM zur Verfügung stehen.
• CPU-Limit: Kann die Nutzung eines Gastes begrenzen. Es schafft keine zusätzliche physische Rechenleistung.
• CPU-Gewichtung: Beeinflusst die relative Verteilung verfügbarer CPU-Zeit, wenn Konkurrenz auftritt. Sie ist keine feste Zusage für eine bestimmte Leistung.
• CPU-Bindung: Kann virtuelle Prozessoren an bestimmte Host-CPUs binden. Sie ist ein gezieltes Werkzeug für passende Anwendungsfälle, kein allgemeiner Ersatz für Kapazitätsplanung.

Prüfen Sie die Namen und das Verhalten der Optionen für die konkret eingesetzte PVE-Version. Die offizielle Dokumentation zu den VM-Verwaltungsbefehlen beschreibt die verfügbaren Parameter. Ändern Sie Limits, Gewichte oder CPU-Zuordnungen erst, nachdem der Ausgangszustand dokumentiert wurde. Prüfen Sie außerdem, ob Gastbetriebssystem und VM-Konfiguration eine Änderung im laufenden Betrieb unterstützen; andernfalls planen Sie einen Neustart im Wartungsfenster ein.

Host und Gäste gemeinsam beobachten

Ein einzelner Messwert kann täuschen. Eine kurze Lastspitze ist nicht automatisch eine dauerhafte Überlastung. Ein stark ausgelasteter Gast beweist ebenfalls nicht, dass der Host keine Reserve mehr hat. Umgekehrt kann eine Anwendung trotz moderater Durchschnittswerte zu bestimmten Zeiten auf CPU-Rechenzeit warten.

Gehen Sie die Signale gemeinsam durch:

1. Host-CPU beobachten. Erfassen Sie die Gesamtauslastung und, soweit verfügbar, die Belegung einzelner CPU-Threads. Prüfen Sie, ob Spitzen kurz bleiben oder über den relevanten Zeitraum anhalten.
2. Gäste gegenüberstellen. Vergleichen Sie die CPU-Nutzung der betroffenen VM mit anderen Gästen. Bei Linux-Gästen zeigt die Anzeige der CPU-Statistiken in top unter anderem den Anteil st für gestohlene CPU-Zeit. Das ist ein Hinweis auf Wartezeit, aber kein eigenständiger Beweis für die Ursache.
3. Lastverlauf einordnen. uptime und /proc/loadavg helfen, die Entwicklung der Systemlast zu betrachten. Die Linux-Manpage erklärt, dass die Load-Average-Werte ausführbare und nicht unterbrechbare Aufgaben berücksichtigen. Ein hoher Wert lässt sich deshalb nicht ohne weitere Prüfung als CPU-Konkurrenz interpretieren.
4. Druckindikatoren kontrollieren. Auf Linux-Systemen können Dateien unter /proc/pressure/ Hinweise darauf geben, wie häufig Aufgaben wegen Ressourcenknappheit warten. Interpretieren Sie CPU-Druck zusammen mit Anwendungsreaktion, Gastmessungen und Hostauslastung.
5. Nicht-CPU-Ursachen ausschließen. Prüfen Sie Datenträgerwartezeiten, Speicherknappheit und Netzwerkprobleme. Ein langsamer Dienst bei niedriger CPU-Nutzung spricht dafür, weitere Ressourcen zu untersuchen, statt zuerst vCPUs zu ändern.

Die Dokumentation zum Linux-Load-Average hilft bei der Einordnung dieses Werts. Community-Beiträge wie die Diskussion im Proxmox-Forum zu dauerhaft hoher CPU-Auslastung oder ein Proxmox-Community-Beitrag zur vCPU-Überbuchung zeigen unterschiedliche Erfahrungen. Sie sind keine offiziellen Empfehlungen und ersetzen keine Messung auf dem eigenen Host.

Erster Prüfzyklus: messen, anpassen, vergleichen

Eine vCPU-Planung ist belastbarer, wenn sie als wiederholbarer Prüfzyklus umgesetzt wird. Ändern Sie nicht mehrere Ressourceneinstellungen gleichzeitig: Sonst bleibt unklar, welche Änderung die beobachtete Wirkung verursacht hat.

1. Bestand aufnehmen. Notieren Sie Host-CPU, aktive VMs, jeweilige vCPU-Zahl und Aufgabenprofil. Mit lscpu lässt sich die vom Host erkannte CPU-Struktur prüfen; die VM-Konfigurationen können Sie mit qm config <VMID> kontrollieren.
2. Betriebsziel festlegen. Definieren Sie, welche Dienste bei Spitzenzeiten Vorrang haben und welche Verzögerung für weniger kritische Gäste akzeptabel ist. Halten Sie dies pro Dienstgruppe fest.
3. Relevante Zeiträume erfassen. Beobachten Sie die Systeme während repräsentativer Betriebsphasen einschließlich geplanter Hintergrundaufgaben. Notieren Sie Zeitpunkte, betroffene Gäste, Reaktionsprobleme und Messwerte.
4. Ursache eingrenzen. Prüfen Sie, ob Gast und Host gleichzeitig hohe CPU-Nachfrage zeigen. Stellen Sie daneben Druckindikatoren, Load Average und mögliche I/O-Wartezeiten. Verwerfen Sie keine Alternativerklärung, nur weil die vCPU-Summe hoch erscheint.
5. Eine Maßnahme auswählen. Reduzieren Sie ein unnötig großes Kontingent, passen Sie ein Limit oder eine Gewichtung an oder verschieben Sie unkritische Aufgaben. Wählen Sie nur eine Änderung, deren Wirkung anschließend messbar ist.
6. Änderung absichern. Sichern Sie die Konfiguration und halten Sie die vorherigen Werte fest. Bei einem Eingriff, der einen Neustart oder eine Änderung am laufenden Dienst erfordert, stimmen Sie das Wartungsfenster ab und planen Sie die Rückkehr zur dokumentierten Konfiguration.
7. Ergebnis vergleichen. Wiederholen Sie die Beobachtung unter möglichst ähnlicher Last. Bewerten Sie Anwendungslatenz, Gastwartezeit und Hostverhalten gemeinsam. Bleibt die Verbesserung aus oder verschlechtert sich ein anderer Dienst, nehmen Sie die Änderung zurück und prüfen Sie die nächste Ursache.

Für die VM-Konfiguration ist die Syntax versionsabhängig anhand der offiziellen Befehlsreferenz zu prüfen. Verändern Sie produktive VMs nicht auf Verdacht mit einem Befehl aus einem fremden Beispiel. Eine angepasste vCPU-Zahl kann je nach Konfiguration und Gastunterstützung zusätzliche Schritte oder einen Neustart erfordern.

Entscheidung nach Eignung bewerten

Die folgende qualitative Bewertung ist kein Leistungstest. Sie ordnet ein, welche Planungsrichtung zu einem beobachteten Lastprofil passt. Bewerten Sie jede VM-Gruppe einzeln, bevor Sie einen Wert für den gesamten Host festlegen.

• Flexible Entwicklungs- und Testlast – Eignung für Überbuchung: hoch, sofern Messungen Reserve zeigen. Schwankende Nachfrage kann zeitlich verteilt sein. Bleiben Reaktionsverhalten und CPU-Druck auch während repräsentativer Spitzen stabil, kann eine höhere Summe zugeteilter vCPUs als die gleichzeitig verfügbare Hostkapazität vertretbar sein. Prüfen Sie diesen Zustand erneut, sobald sich Arbeitsabläufe oder Teamnutzung ändern.
• Interne Dienste mit klaren Prioritäten – Eignung: mittel. Eine moderate Überbuchung ist nur dann sinnvoll, wenn Spitzenzeiten bekannt sind und kritische Dienste geschützt werden. Beobachten Sie, ob Hintergrundaufgaben die Reaktion wichtiger Anwendungen beeinträchtigen. Wenn ja, staffeln Sie Aufgaben oder weisen Sie Prioritäten gezielter zu.
• Dauerhafte, parallel rechnende Aufgaben – Eignung: gering, solange keine Reserve nachgewiesen ist. Wenn mehrere VMs kontinuierlich CPU-Zeit benötigen, können sich Wartezeiten auch bei sorgfältig gewählten vCPU-Kontingenten summieren. Vermeiden Sie, den Engpass mit zusätzlichen virtuellen Prozessoren zu kaschieren.

Entscheidungshilfe zum Abhaken

Prüfen Sie die Punkte für die betroffene VM-Gruppe. Markieren Sie nur, was sich mit Messungen oder Betriebsaufzeichnungen belegen lässt.

• [ ] Die Spitzenlast wurde beobachtet; ruhige Zeiträume wurden nicht als Ersatz für Spitzenmessungen verwendet.
• [ ] Host- und Gastwerte wurden für denselben Zeitraum verglichen.
• [ ] CPU-Wartezeichen oder Druckindikatoren treten wiederholt gleichzeitig mit einer Verschlechterung wichtiger Anwendungen auf.
• [ ] Speicher-, Datenträger- und Netzwerkengpässe wurden als alternative Ursachen geprüft.
• [ ] Große vCPU-Kontingente werden von den jeweiligen Anwendungen tatsächlich genutzt.
• [ ] Kritische Dienste und weniger wichtige Hintergrundlasten sind nach ihrer Bedeutung eingeordnet.

Leiten Sie daraus die nächste Maßnahme ab:

• Wenn die ersten beiden Punkte erfüllt sind, aber keine wiederkehrenden Konkurrenzsignale auftreten, dann lassen Sie die Zuteilung vorerst bestehen und setzen Sie die Beobachtung fort.
• Wenn wiederkehrende Konkurrenzsignale auftreten und ein oder mehrere große Kontingente ungenutzt bleiben, dann testen Sie eine kleinere vCPU-Zahl für diese Gäste. Sichern Sie zuvor die Konfiguration und vergleichen Sie das Verhalten unter ähnlicher Last.
• Wenn nur bestimmte Aufgaben zeitlich zusammenfallen, dann staffeln Sie diese Lasten oder passen Sie die Priorisierung an, bevor Sie den Host austauschen.
• Wenn Konkurrenz trotz sinnvoller vCPU-Zahlen, Priorisierung und Lastverteilung bestehen bleibt, dann prüfen Sie eine Aufteilung der Arbeitslast oder zusätzliche physische CPU-Kapazität.
• Wenn die Anwendung langsam ist, aber CPU-Wartezeichen fehlen, dann kehren Sie nicht vorschnell eine CPU-Entscheidung um; untersuchen Sie zuerst Speicher, Datenträger, Netzwerk und Gastkonfiguration.

Kapazität anhand realer Konfigurationen neu prüfen

Eine Erweiterung ist sinnvoll, wenn Messungen in repräsentativen Spitzen wiederkehrende Konkurrenz zeigen und weder die vCPU-Zuteilung noch die Aufgabenverteilung den Engpass beheben. Mehr vCPUs für Gäste lösen diesen Mangel nicht. Sie können die Konkurrenz sogar verschärfen, wenn zusätzliche virtuelle Prozessoren gleichzeitig CPU-Zeit anfordern.

Für die Bewertung einer dedizierten Servermiete sollten Lastdaten und Produktmerkmale getrennt betrachtet werden. NodeKVM bietet laut Konfigurations- und Preisübersicht einen AMD EPYC 7543P mit 32 Kernen und 64 Threads sowie Arbeitsspeicheroptionen mit 128 GB oder 256 GB ECC RDIMM. Diese Angaben beschreiben die angebotene Hardware, nicht die Leistung einer konkreten VM oder eine garantierte Zahl gleichzeitig betreibbarer Gäste.

Die Auswahl des Arbeitsspeichers sollte zum geplanten VM-Bestand passen. Die Speicheroption ist nicht nachträglich durch zusätzliche Speichermodule erweiterbar; wer 256 GB benötigt, muss die entsprechende Ausführung wählen. Für Datenträger stehen zwei direkt angebundene NVMe-Laufwerke mit je 1 TB bereit; laut Produktangaben kann die Ausstattung um bis zu zwei zusätzliche 2-TB-NVMe-Laufwerke ergänzt werden. Das ersetzt weder eine eigene Ausfallsicherheitsplanung noch eine externe Sicherung.

Beim Netzanschluss sind 250 Mbit/s, 1 Gbit/s oder 2 Gbit/s mit unbegrenztem Datenvolumen auswählbar. Die passende Option richtet sich nach Netzwerkverkehr und Dienstprofil, nicht nach der CPU-Quote. Für den Abgleich von Bandbreite und Nutzung bietet der Leitfaden zur Auswahl eines unbegrenzten Anschlusses einen eigenen Entscheidungsschwerpunkt.

Als Systeme sind unter anderem Proxmox VE 8 und 9 verfügbar. Die Abrechnung ist monatlich, vierteljährlich, halbjährlich oder jährlich möglich; konkrete Beträge und Auswahlmöglichkeiten sind der aktuellen Produktübersicht zu entnehmen. Prüfen Sie vor einer Bestellung, ob CPU, Speicher, Datenträger und Anschluss zu den gemessenen Spitzen Ihrer Arbeitslast passen. Eine Hardwareliste allein belegt nicht, dass ein bestimmtes VM-Profil darauf ohne Engpässe läuft.

Häufige Fragen zur vCPU-Planung

Darf die Summe der vCPUs über der Threadzahl des Proxmox-Hosts liegen?

Ja. Die vCPU-Zahl beschreibt die den Gästen zugewiesenen virtuellen Prozessoren, keine Zusage, dass alle gleichzeitig eigene physische Rechenzeit erhalten. Eine Überbuchung kann bei wechselnder oder geringer Parallelität funktionieren. Entscheidend ist, ob die gleichzeitige Spitzenlast die verfügbaren Hostressourcen regelmäßig überfordert. Prüfen Sie deshalb Auslastung und Warteindikatoren statt nur die Kontingentsumme.

Soll die CPU-Überbuchungsquote anhand physischer Kerne oder Threads berechnet werden?

Beide Angaben beschreiben unterschiedliche Aspekte der Hostkapazität. Physische Kerne sind eine nachvollziehbare Planungsbasis; logische Threads zeigen, wie viele Ausführungskontexte das Betriebssystem sieht. Daraus folgt jedoch keine universelle Zusage gleicher Rechenleistung pro Thread. Dokumentieren Sie beide Werte und bewerten Sie sie zusammen mit der gemessenen Last Ihrer konkreten Anwendungen.

Woran lässt sich eine CPU-Konkurrenz zwischen Proxmox-VMs erkennen?

Achten Sie auf wiederkehrende Verzögerungen während der Spitzenlast, hohe oder anhaltende Hostauslastung und CPU-Wartezeit in den Gästen. Vergleichen Sie diese Signale zeitlich mit Host- und Gastmessungen; ein einzelner hoher Lastwert beweist noch keine Überbuchung. Untersuchen Sie auch I/O-Wartezeiten und die Anwendungslatenz, bevor Sie vCPU-Kontingente verändern.

Sollten bei stockenden VMs vCPUs reduziert oder ein größerer Server gewählt werden?

Reduzieren Sie zuerst unnötig große vCPU-Zuteilungen oder ordnen Sie unkritische Lasten anders zu, wenn die Messwerte dafür sprechen. Bleibt die Konkurrenz in repräsentativen Spitzenzeiten bestehen und lässt sie sich nicht durch Priorisierung oder Verteilung beheben, prüfen Sie mehr physische CPU-Kapazität. Mehr vCPUs allein lösen einen Mangel an Host-Rechenzeit nicht.

Wenn Messprotokolle eine wiederkehrende CPU-Konkurrenz belegen, sollte die nächste Entscheidung nicht auf einer allgemeinen Überbuchungsquote beruhen. Vergleichen Sie Spitzenlast, wichtige VM-Dienste und benötigte Speicher- und Datenträgerkapazität mit den realen Optionen für einen dedizierten Server. Eine gemeinsam genutzte Instanz kann für geringe, unregelmäßige Last sinnvoll bleiben; bei dauerhaft benötigter CPU-Zeit können geteilte Hostressourcen, nicht transparente Kontingente und eingeschränkte Kontrolle über die Hardware jedoch die Kapazitätsplanung erschweren. Prüfen Sie die konkreten Optionen von NodeKVM und entscheiden Sie erst nach diesem Abgleich, ob ein Umzug auf einen unabhängigen AMD-Server zum gemessenen Betrieb passt. Die Produktübersicht von NodeKVM enthält die verfügbaren Auswahlmöglichkeiten für die weitere Prüfung.

Fragen

1. Q
   Darf die Summe der vCPUs über der Threadzahl des Proxmox-Hosts liegen?

   Ja. Die vCPU-Zahl beschreibt die den Gästen zugewiesenen virtuellen Prozessoren, keine Zusage, dass alle gleichzeitig eigene physische Rechenzeit erhalten. Eine Überbuchung kann bei wechselnder oder geringer Parallelität funktionieren. Entscheidend ist, ob die gleichzeitige Spitzenlast die verfügbaren Hostressourcen regelmäßig überfordert. Prüfen Sie deshalb Auslastung und Warteindikatoren statt nur die Kontingentsumme.

2. Q
   Soll die CPU-Überbuchungsquote anhand physischer Kerne oder Threads berechnet werden?

   Beide Angaben beschreiben unterschiedliche Aspekte der Hostkapazität. Physische Kerne sind eine nachvollziehbare Planungsbasis; logische Threads zeigen, wie viele Ausführungskontexte das Betriebssystem sieht. Daraus folgt jedoch keine universelle Zusage gleicher Rechenleistung pro Thread. Dokumentieren Sie beide Werte und bewerten Sie sie zusammen mit der gemessenen Last Ihrer konkreten Anwendungen.

3. Q
   Woran lässt sich eine CPU-Konkurrenz zwischen Proxmox-VMs erkennen?

   Achten Sie auf wiederkehrende Verzögerungen während der Spitzenlast, hohe oder anhaltende Hostauslastung und CPU-Wartezeit in den Gästen. Vergleichen Sie diese Signale zeitlich mit Host- und Gastmessungen; ein einzelner hoher Lastwert beweist noch keine Überbuchung. Untersuchen Sie auch I/O-Wartezeiten und die Anwendungslatenz, bevor Sie vCPU-Kontingente verändern.

4. Q
   Sollten bei stockenden VMs vCPUs reduziert oder ein größerer Server gewählt werden?

   Reduzieren Sie zuerst unnötig große vCPU-Zuteilungen oder ordnen Sie unkritische Lasten anders zu, wenn die Messwerte dafür sprechen. Bleibt die Konkurrenz in repräsentativen Spitzenzeiten bestehen und lässt sie sich nicht durch Priorisierung oder Verteilung beheben, prüfen Sie mehr physische CPU-Kapazität. Mehr vCPUs allein lösen einen Mangel an Host-Rechenzeit nicht.