Ich versuche schon seit einiger Zeit herauszufinden, warum bei vielen unserer geschäftskritischen Systeme Meldungen über „Langsamkeit“ von leicht bis extrem eingehen. Ich habe mir kürzlich die VMware-Umgebung angesehen, in der alle betreffenden Server gehostet werden.
Ich habe vor Kurzem die Testversion des Veeam VMware Management Pack für SCOM 2012 heruntergeladen und installiert, aber mir fällt es schwer (und meinem Chef auch), die mir angezeigten Zahlen zu glauben. Um meinen Chef davon zu überzeugen, dass die mir angezeigten Zahlen stimmen, habe ich begonnen, den VMware-Client selbst zu untersuchen, um die Ergebnisse zu überprüfen.
Ich habe mir angesehendieser VMware KB-Artikel; insbesondere für die Definition von Co-Stop, die wie folgt definiert ist:
Zeitspanne, in der eine virtuelle MP-Maschine betriebsbereit war, es jedoch aufgrund von Co-vCPU-Planungskonflikten zu einer Verzögerung kam
Was ich übersetze
Das Gastbetriebssystem benötigt Zeit vom Host, muss aber warten, bis Ressourcen verfügbar werden und kann daher als „nicht reagierend“ betrachtet werden.
Scheint diese Übersetzung richtig zu sein?
Wenn ja, dann fällt es mir schwer zu glauben, was ich sehe: Der Host, der die Mehrheit der "langsamen" VMs enthält, zeigt derzeit einen CPU-Co-Stop-Durchschnitt von127.835,94Millisekunden!
Bedeutet dies, dass die VMs auf diesem Host im Durchschnitt mehr als 2 Minuten auf die CPU-Zeit warten müssen???
Dieser Host verfügt über zwei 4-Kern-CPUs und hat 1x8-CPU-Gast und 14x4-CPU-Gäste.
Antwort1
Ich kann einige meiner Erfahrungen auf diesem Gebiet schildern …
Ich glaube nicht, dass VMware die Kunden ausreichend informiert (oder Administratoren) über Best Practices, noch aktualisieren sie frühere Best Practices, wenn sich ihre Produkte weiterentwickeln. Diese Frage ist ein Beispiel dafür, dass ein Kernkonzept wie die vCPU-Zuweisung nicht vollständig verstanden wird. Der beste Ansatz besteht darin, klein anzufangen, mit einer einzigen vCPU, bis Sie feststellen, dass die VM mehr benötigt.
Für den OP verfügt der ESXi-Hostserver über zwei Quad-Core-CPUs, was 8 physische Kerne ergibt.
Das beschriebene virtuelle Maschinenlayout umfasst insgesamt 15 Gäste; 1 x 8 vCPU und 14 x 4 vCPU-Systeme. Das ist viel zu viel, insbesondere bei der Existenz eineseinzelner Gast mit 8 vCPUs. Das ergibt keinen Sinn. Wenn Sie eine so große VM benötigen, brauchen Sie wahrscheinlich einen größeren Server.
Bitte versuche zurichtige GrößeIhre virtuellen Maschinen. Ich bin ziemlich sicher, dass die meisten von ihnen mit 2 vCPUs auskommen. Das Hinzufügen virtueller CPUs macht die Dinge nicht schneller. Wenn das also ein Leistungsproblem beheben soll, ist es der falsche Ansatz.
In den meisten Umgebungen ist RAM die am stärksten eingeschränkte Ressource. Aber die CPU kann ein Problem darstellen, wenn es zu viele Konflikte gibt. Sie haben Beweise dafür. RAM kann auch ein Problem darstellen, wennzu viel wird einzelnen VMs zugewiesen.
Dies lässt sich überwachen. Die gesuchte Metrik ist „CPU Ready %“. Sie können darauf über den vSphere-Client zugreifen, indem Sie eine VM auswählen und zu Performance> Overview> CPU-Diagramm gehen.
- Unter 5 % CPU-Bereitschaft- Du bist in Ordnung.
- 5–10 % CPU bereit- Behalten Sie die Aktivitäten genau im Auge.
- Über 10 % CPU-bereit- Nicht gut.
Beachten Sie die gelbe Linie in der Grafik unten.
Würde es Ihnen etwas ausmachen, dies auf Ihren problematischen virtuellen Maschinen zu überprüfen und uns darüber zu informieren?
Antwort2
Sie geben in den Kommentaren an, dass Sie einen Dual-Quad-Core-ESXi-Host haben und eine 8vCPU-VM ausführen.vierzehn4vCPU-VMs.
Wenn dies meine Umgebung wäre, würde ich das alsgrobüberprovisioniert. Ich würde höchstens vier bis sechs 4vCPU-Gäste auf diese Hardware setzen. (Dies setzt voraus, dass die betreffenden VMs eine Auslastung aufweisen, die eine so hohe vCPU-Anzahl erfordert.)
Ich nehme an, Sie kennen die goldene Regel nicht … bei VMware sollten Sie einer VM nie mehr Kerne zuweisen, als sie benötigt. Grund? VMware verwendet eine ziemlich strikte Co-Scheduling-Methode, die es VMs erschwert, CPU-Zeit zu erhalten, es sei denn, es sind so viele Kerne verfügbar, wie der VM zugewiesen sind. Das bedeutet, dass eine 4vCPU-VM keine Arbeitseinheit ausführen kann, wenn nicht gleichzeitig 4 physische Kerne geöffnet sind. Mit anderen Worten: Es ist architektonisch besser, eine 1vCPU-VM mit 90 % CPU-Last zu haben, als eine 2vCPU-VM mit 45 % Auslastung pro Kern.
Erstellen Sie also IMMER VMs mit einem Minimum an vCPUs und fügen Sie sie nur hinzu, wenn es als notwendig erachtet wird.
Verwenden Sie in Ihrer Situation Veeam, um die CPU-Auslastung Ihrer Gäste zu überwachen. Reduzieren Sie die vCPU-Anzahl bei so vielen wie möglich. Ich würde wetten, dass Sie bei fast allen Ihrer vorhandenen 4vCPU-Gäste auf 2vCPU reduzieren könnten.
Zugegeben, wenn alle diese VMs tatsächlich die CPU-Auslastung haben, um die vorhandene Anzahl an vCPUs zu erfordern, müssen Sie einfach zusätzliche Hardware kaufen.
Antwort3
Die 127.835,94 Millisekunden sind eine Summe und Sie müssen sie durch die Abtastzeit dividieren, um die korrekten %RDY-Werte zu erhalten. Es sieht jedoch so aus, als würden Sie jetzt bereits die korrekten %RDY-Werte erhalten. Sie können das Verhältnis von vCPU zu physischer CPU ziemlich hoch ansetzen, aber nicht auf die Art, wie Sie es tun.
Sie haben viel zu viele Quad-vCPU-VMs und sogar eine 8-vCPU-VM. Es gibt bereits einige gute Antworten, in denen die richtige Dimensionierung und einige Konsequenzen einer Nichtkonsolidierung der Zyklen auf weniger vCPUs diskutiert werden. Ich wollte nur klarstellen, dass eine VM zwar nicht mehr warten muss, bis die Anzahl physischer CPUs, die ihrer Anzahl an vCPUs entspricht, verfügbar ist, bevor eine Anweisung verarbeitet werden kann, es jedoch sehr schädlich ist, eine Überbereitstellung dieser Größenordnung bei dem Verhältnis von Multi-vCPU-VMs zu physischen Kernen zu haben. 64 vCPUs auf 8 Kernen liegen weit über dem maximalen Verhältnis von 4 zu 1. Ich nehme an, Sie haben HT auf diesen Prozessoren, also haben Sie 16 logische Kerne? Das könnte bei 1- und 2-vCPU-VMs mit geringer Auslastung in Ordnung sein, aber wenn die VMs stark ausgelastet sind, wäre dies schwer zu erreichen.
Zu Ihrer Information: Die HT-Prozessoren werden bei der Berechnung der CPU-Auslastung in Prozent nicht berücksichtigt. Das bedeutet, dass Sie bei einem Server mit 32 logischen Kernen, die mit 2,4 GHz laufen, bei 38,4 GHz eine Auslastung von 100 % haben. Wenn Sie also sehen, dass die durchschnittliche Auslastung über 1,0 liegt, ist das der Grund.
Hier ist ein ESXi-Host, der ein Verhältnis von 3,5 zu 1 vCPU zu physischer CPU (einschließlich HT-Kernen) mit einem durchschnittlichen %RDY von 3 % ausführt.
11:13:49pm up 125 days 7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37
%USED %RUN %SYS %WAIT %VMWAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
13.51 15.87 0.50 580.17 0.03 4.67 66.47 0.29 0.00 0.00 0.00
15.24 18.64 0.43 491.54 0.04 4.65 63.70 0.43 0.00 0.00 0.00
13.44 16.40 0.44 494.10 0.02 4.33 66.24 0.48 0.00 0.00 0.00
13.75 16.30 0.51 494.26 0.32 4.32 66.06 0.35 0.00 0.00 0.00
17.56 20.72 0.58 489.35 0.04 4.31 60.76 0.45 0.00 0.00 0.00
13.82 16.43 0.50 494.12 0.07 4.31 66.26 0.26 0.00 0.00 0.00
13.65 16.81 0.49 493.81 0.03 4.21 65.93 0.37 0.00 0.00 0.00
13.73 16.51 0.42 493.63 0.09 4.06 66.24 0.29 0.00 0.00 0.00
13.89 16.37 0.55 580.61 0.04 3.95 66.69 0.28 0.00 0.00 0.00
14.02 17.00 0.33 494.11 0.03 3.93 66.10 0.29 0.00 0.00 0.00
13.44 15.84 0.49 495.17 0.04 3.87 67.24 0.27 0.00 0.00 0.00
13.59 15.84 0.50 580.27 0.04 3.81 67.24 0.44 0.00 0.00 0.00
17.10 19.86 0.50 490.97 0.04 3.74 62.21 0.39 0.00 0.00 0.00
13.32 15.77 0.50 495.34 0.03 3.73 67.47 0.27 0.00 0.00 0.00
13.43 16.15 0.48 494.95 0.05 3.72 67.09 0.38 0.00 0.00 0.00
13.44 16.47 0.49 580.88 0.04 3.72 66.81 0.40 0.00 0.00 0.00
13.71 17.00 0.29 494.13 0.03 3.71 66.26 0.37 0.00 0.00 0.00
17.34 20.41 0.39 490.50 0.05 3.70 61.70 0.37 0.00 0.00 0.00
13.42 16.19 0.50 495.07 0.03 3.66 67.15 0.38 0.00 0.00 0.00
13.56 16.23 0.48 494.97 0.03 3.60 67.12 0.30 0.00 0.00 0.00
14.95 17.53 0.42 578.82 0.09 3.57 65.72 0.35 0.00 0.00 0.00
13.44 16.07 0.56 581.14 0.04 3.54 67.34 0.40 0.00 0.00 0.00
17.19 21.27 0.37 575.41 0.04 3.44 61.08 0.51 0.00 0.00 0.00
13.57 16.99 0.30 580.64 0.01 3.37 66.69 0.38 0.00 0.00 0.00
13.79 16.25 0.43 495.25 0.04 3.35 67.39 0.39 0.00 0.00 0.00
11.90 14.67 0.30 496.86 0.02 3.31 69.00 0.36 0.00 0.00 0.00
17.13 19.28 0.56 491.83 0.03 3.30 63.26 0.48 0.00 0.00 0.00
14.01 16.17 0.50 495.56 0.01 3.30 67.66 0.39 0.00 0.00 0.00
16.86 20.16 0.57 491.19 0.05 3.20 62.44 0.43 0.00 0.00 0.00
14.94 17.46 0.42 580.05 0.08 3.16 66.24 0.40 0.00 0.00 0.00
14.56 16.94 0.36 494.86 0.08 3.14 66.91 0.42 0.00 0.00 0.00
......
Antwort4
Wir haben inzwischen Veeam ONE installiert, was uns einiges an Licht in die Lage versetzt hat, unsere Leistungsprobleme zu beheben. Indem wir uns den Bildschirm „CPU-Engpässe“ in Veeam ONE ansehen und dannFehlerbehebung bei einer virtuellen Maschine, die nicht mehr reagiert: Vergleich der CPU-Auslastung von VMM und Gastals Referenz haben wir herausgefunden, wo viele unserer „inakzeptablen“ Behauptungen liegen.
Ein kleiner Tipp, den ich besonders weitergeben wollte, ist, dass ich in einem Fall die CPU-Konflikte nicht beseitigen konnte, bis ich den Snapshot entfernte, der sich auf der VM befand. Ich hoffe, das hilft jemandem.