Dennis HilkLinux Fix LabEN

Leistung und Virtualisierung

Ein Gast verliert CPU-Zeit durch Host-Konkurrenz oder Grenzen

Ein Gast wirkt CPU-arm trotz ungenutzter vCPUs. Vergleiche Gast-Steal-Zeit mit Host-Platzierung und Grenzen vor dem Hinzufügen weiterer vCPUs.

Redaktionelle Quellenprüfung: Mit den Hinweisen beginnenAnleitung teilen
Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Gastantworten werden bei weiteren aktiven Hostlasten langsamer.
  • Gast-Steal-Zeit steigt oder vCPU-Pinning konzentriert Arbeit auf wenige Host-CPUs.

Betroffene Umgebung

Linux-Gäste unter QEMU/libvirt; Steal-Anzeige hängt vom Hypervisor ab und erfasst nicht jede Scheduling-Verzögerung.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Überbuchte Host-CPUs oder enge Bindung können ausführbare virtuelle CPU-Threads verzögern.
  • vCPU- oder Gesamt-Domain-Kontingente können Zeit begrenzen; mehr vCPUs erhöht das Budget nicht automatisch.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Führe die sysstat-Stichprobe im Linux-Gast aus; benötigt installiertes mpstat.

mpstat -P ALL 1 5

Ergebnis einordnen: %steal ist unfreiwillige vCPU-Wartezeit bei anderer Hypervisorarbeit. Hohe Werte stützen Hostkonkurrenz; null schließt nicht jede Hypervisor- oder Kontingentverzögerung aus.

Prüfschritt 2

Führe dies auf dem Host mit passendem Domainnamen aus; ohne CPU- und vCPU-Zuweisung ist es eine reine Abfrage.

virsh -c qemu:///system vcpupin example-vm

Ergebnis einordnen: Vergleiche erlaubte Host-CPUs mit Last und Topologie. Mehrere aktive vCPUs an einer Host-CPU konkurrieren trotz großer Gasttopologie.

Prüfschritt 3

Liest Schedulerwerte mit vorhandenem libvirt-Zugriff; ergänze kein --set oder Zuweisungen.

virsh -c qemu:///system schedinfo example-vm

Ergebnis einordnen: Endliches vcpu_quota oder global_quota kann das Budget erklären. Laufende und dauerhafte XML können abweichen; prüfe den passenden Zustand vor Änderungen.

Nächste Schritte nach Befund

Gast- und Host-CPU-Zuteilung passend wählen

Wenn Hostkonkurrenz gemessen ist, reduziere parallele Nachbaraufträge oder passe vCPU-Zahl an verfügbare Kapazität an. Behebe unbeabsichtigte enge Bindung unter Erhalt gewünschter Isolation.

Vorsicht: Mehr vCPUs können Konkurrenz verschärfen und garantieren keinen Durchsatz. Beachte Emulator- und I/O-Thread-Platzierung bei Affinitätsprüfung.

Wiederherstellung / Rücknahme: Stelle vCPU-Topologie und Bindung im selben Laufzeit-/Dauerkontext zurück; starte nur bei erforderlicher Gaständerung neu.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Vorgesehenes Domain-CPU-Budget korrigieren

Wenn ein unbeabsichtigtes endliches Kontingent begrenzt, passe vCPU- oder Gesamtbudget dieser Domain mit gemessener Hostreserve durch libvirt an. Bei bewusstem Budget reduziere Gastparallelität.

Vorsicht: Gesamt- und Einzel-vCPU-Kontingente wirken verschieden. Mehr Domainbudget kann Nachbargäste verschlechtern.

Wiederherstellung / Rücknahme: Stelle Kontingent/Periode und Gastparallelität zurück und vergleiche dieselbe Gast- und Hostlast.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.