Frage Wie viel Konkurrenz ist in VMware zu viel?


Seit einiger Zeit versuche ich herauszufinden, warum einige unserer geschäftskritischen Systeme Berichte über "Langsamkeit" von mild bis extrem erhalten. Ich habe mich kürzlich auf die VMware-Umgebung konzentriert, in der alle betroffenen Server gehostet werden.

Ich habe kürzlich die Testversion für das Veeam VMware Management Pack für SCOM 2012 heruntergeladen und installiert, aber es fällt mir schwer, die Zahlen, die es mir berichtet, zu schätzen (und auch mein Chef). Um zu versuchen, meinen Chef davon zu überzeugen, dass die Zahlen, die er mir sagt, wahr sind, habe ich begonnen, den VMware-Client selbst zu untersuchen, um die Ergebnisse zu überprüfen.

Ich habe es angeschaut Dieser VMware KB-Artikel; speziell für die Definition von Co-Stop, definiert als:

Zeit, in der eine virtuelle MP-Maschine zur Ausführung bereit war, aber anfallen konnte   Verzögerung aufgrund von Co-vCPU-Zeitplanungskonflikten

Zu dem ich übersetze

Das Gastbetriebssystem benötigt Zeit vom Host, muss jedoch auf die Verfügbarkeit von Ressourcen warten und kann daher als "nicht reagierend" betrachtet werden.

Scheint diese Übersetzung korrekt?

Wenn dem so ist, fällt es mir schwer, zu glauben, was ich sehe: Der Host, der die Mehrzahl der VMs enthält, die "langsam" sind, zeigt derzeit einen CPU-Co-Stop-Durchschnitt von 127,835.94 Millisekunden!

Bedeutet dies, dass im Durchschnitt die VMs auf diesem Host 2+ Minuten auf die CPU-Zeit warten müssen ???

Dieser Host hat zwei 4-Kern-CPUs und es hat 1x8 CPU Gäste und 14x4 CPU Gäste.


20
2018-02-20 14:11


Ursprung


Aus meiner Sicht: Um einige Probleme zu vermeiden, werden alle virtuellen CPUs einer VM zur gleichen Zeit ausgeführt. Wenn es Streit gibt, können einige VMs wirklich langsam laufen. Hinweis: Wenn Sie VMs mehr vCPUs zuweisen, um die Leistung zu verbessern, wenn dies das Problem ist, wird sich die Situation verschlimmern. - Brian
Dieser Host hat zwei 4-Kern-CPUs und es hat 1x8 CPU Gäste und 14x4 CPU Gäste. - Chuck Herrington
Warum haben so viele Gäste 4 vCPU-Konfigurationen? - ewwhite
CPU Co-Scheduling-Konkurrenz bringt Sie um. Sie müssen die vCPU-Anzahl reduzieren oder einige VMs von diesem System entfernen. - Brian
@ChuckHerrington Du solltest nachgehen oder eine Antwort markieren. - ewwhite


Antworten:


Ich kann einige der Erfahrungen beschreiben, die ich in diesem Bereich gemacht habe ...

Ich glaube nicht, dass VMware eine adäquate Aufgabe der Kundenerziehung leistet (oder Administratoren) über Best Practices, noch aktualisieren sie frühere Best Practices, wenn sich ihre Produkte weiterentwickeln. Diese Frage ist ein Beispiel dafür, wie ein Kernkonzept wie die vCPU-Zuweisung nicht vollständig verstanden wird. Der beste Ansatz besteht darin, klein mit einer einzigen vCPU zu beginnen, bis Sie feststellen, dass die VM mehr benötigt.

Für den OP verfügt der ESXi-Hostserver über zwei Quad-Core-CPUs mit 8 physischen Kernen.

Das beschriebene Layout der virtuellen Maschine beträgt 15 Gäste. 1 x 8 vCPU- und 14 x 4 vCPU-Systeme. Das ist viel zu übertrieben, vor allem mit der Existenz eines Einzelner Gast mit 8 vCPUs. Das macht keinen Sinn. Wenn Sie eine so große VM benötigen, benötigen Sie wahrscheinlich einen größeren Server.

Bitte versuche zu richtige Größe Ihre virtuellen Maschinen. Ich bin ziemlich sicher, dass die meisten von ihnen mit 2 vCPU leben können. Das Hinzufügen von virtuellen CPUs sorgt nicht dafür, dass die Dinge schneller laufen. Wenn dies ein Problem für die Performance ist, ist dies der falsche Ansatz.

In den meisten Umgebungen ist RAM die am meisten eingeschränkte Ressource. Aber CPU kann ein Problem sein, wenn es zu viel Konkurrenz gibt. Du hast Beweise dafür. RAM kann auch ein Problem sein, wenn Zu viel wird einzelnen VMs zugewiesen.

Es ist möglich, dies zu überwachen. Die gesuchte Metrik ist "CPU Ready%". Sie können vom vSphere-Client aus darauf zugreifen, indem Sie eine VM auswählen und zu Performance> Overview > CPU-Grafik.

  • Unter 5% CPU Ready - Du bist in Ordnung.
  • 5-10% CPU-fähig - Achte auf die Aktivität.
  • Über 10% CPU Ready - Nicht gut.

Beachten Sie die gelbe Linie in der Grafik unten. enter image description here

Würde es Ihnen etwas ausmachen, dies auf Ihren problematischen virtuellen Maschinen zu überprüfen und zurück zu melden?


17
2018-02-21 00:11



Wir haben uns den Graphen für einen Exchange-Server angesehen, den wir auf diesem überlasteten Host haben. Mein Diagramm sieht invers aus. Die CPU-Auslastung bewegt sich um 25% und CPU Ready-Spitzen um 200%, im Durchschnitt jedoch um 100%. - Chuck Herrington
@ChuckHerrington Bitte reduzieren Sie die Ressourcen der virtuellen Maschine mit 8 vCPU und messen Sie erneut. - ewwhite
Das einzige Problem damit ist, dass der 8-CPU-Gast einer der wichtigsten Serverserver für die Produktionsserver ist. Wir hatten versucht, es auf 4 zu reduzieren und die Dinge gingen ... schief. Schätze, wir versuchen es besser noch einmal. - Chuck Herrington
Sie können keine virtuelle 8CPCPU-Maschine auf einem Server mit 8 Kernen verwenden. - ewwhite
@ewhite leider kannst du, du solltest nicht, aber du kannst. - Rqomey


Sie geben in den Kommentaren an, dass Sie einen Dual-Quad-Core-ESXi-Host haben und eine 8vCPU-VM ausführen vierzehn 4vCPU VMs.

Wenn das meine Umgebung wäre, würde ich das für richtig halten grob überprovisioniert. Ich würde allenfalls vier bis sechs 4vCPU-Gäste auf diese Hardware stellen. (Dies setzt voraus, dass die fraglichen VMs eine Last haben, die sie dazu zwingt, die höchste vCPU-Zählung aufzuweisen.)

Ich gehe davon aus, dass Sie die goldene Regel nicht kennen ... mit VMware sollten Sie einer VM niemals mehr Kerne zuweisen, als sie benötigen. Grund? VMware verwendet eine etwas strikte Co-Planung, die es VMs schwer macht, CPU-Zeit zu erhalten, wenn nicht so viele Kerne verfügbar sind, wie die VM zugewiesen ist. Das bedeutet, dass eine 4vCPU-VM 1 Arbeitseinheit nicht 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 und dann eine 2vCPU-VM mit 45% Auslastung pro Kern.

Also ... IMMER VMs mit einem Minimum an vCPUs erstellen und diese nur hinzufügen, wenn dies als notwendig erachtet wird.

Verwenden Sie für Ihre Situation Veeam, um die CPU-Auslastung Ihrer Gäste zu überwachen. Reduzieren Sie die vCPU-Anzahl auf so viele wie möglich. Ich würde wetten, dass Sie auf fast alle Ihre bestehenden 4vCPU Gäste auf 2vCPU fallen könnten.

Zugegeben, wenn all diese VMs tatsächlich die CPU-Last haben, um die vCPU-Anzahl zu benötigen, die sie haben, dann müssen Sie nur zusätzliche Hardware kaufen.


46
2018-02-20 15:04



Diese Antwort, ich mag es, eine andere! (zerschlägt Kaffeetasse am Boden) - MonkeyZeus
Eine Sache hinzuzufügen. Richten Sie eine Warnung für CPU% bereit ein. davidklee.net/articles/sql-server-articles/... - Stewpudaso
Sollte das nicht eine Unterversorgung sein? - immibis
Ist das VMWare Idiotie immer noch vorhanden? Hyper-V hatte das gleiche - in der ersten Version und es wurde so schnell wie möglich behandelt. Jetzt werden die Kerne unabhängig voneinander geplant. Ich kann mir nicht vorstellen, dass dies für VmWare in der aktuellen Version immer noch der Fall ist. - TomTom
@ TomTom: nach serverfault.com/a/642316/58957 In Versionen vor 3.x (vor mehr als 10 Jahren!) wurde "striktes Co-Scheduling" eingesetzt, doch das Internet ist noch voll davon. Dennoch ist die Empfehlung, die Anzahl der vCPUs nur zu erhöhen, wenn nötig, gut. - Nickolay


Die 127,835.94 Millisekunden ist eine Summe und Sie müssen durch die Abtastzeit teilen, um die richtigen% RDY-Werte zu erhalten. Es sieht so aus, als ob Sie bereits jetzt die korrekten% RDY-Messwerte erhalten. Sie können ziemlich hoch mit der vCPU zu physischen CPU-Verhältnis gehen, aber nicht so, wie Sie es tun.

Sie haben viel zu viele Quad-vCPU-VMs und sogar eine 8-vCPU-VM. Es gibt einige Qualitätsantworten, in denen bereits die richtige Dimensionierung und einige Auswirkungen der Nicht-Konsolidierung von Zyklen auf weniger vCPUs diskutiert werden. Die eine Sache, die ich klarstellen wollte, ist, dass es zwar nicht länger der Fall ist, dass eine VM auf die Anzahl physischer CPUs warten muss, die ihrer Anzahl an vCPUs entspricht, bevor eine Anweisung verarbeitet werden kann, aber sehr schädlich ist übermäßige Bereitstellung dieser Größenordnung mit dem Verhältnis von VMs mit mehreren vCPUs zu physischen Kernen. 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, so dass Sie 16 logische Kerne haben? Bei VMs mit 1 und 2 vCPU, die eine geringe Last haben, ist dies jedoch in Ordnung. Wenn Sie jedoch die VMs stark belasten, ist dies nur schwer möglich.

Hinweis: Die HT-Prozessoren werden nicht in den CPU% -Berechnungen verwendet. Das heißt, wenn Sie einen logischen 32-Core mit 2,4 Ghz auf einem Server betreiben, sind Sie bei einer Auslastung von 38,4 GHz zu 100% ausgelastet. Wenn Sie sehen, dass die Lastdurchschnittswerte mehr als 1,0 betragen, ist das der Grund.

Hier ist ein ESXi-Host, der ein Verhältnis von 3,5 zu 1 vCPU zu physischen CPUs (einschließlich HT-Kernen) mit einem durchschnittlichen% RDY von 3% aufweist.

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

......

2
2018-02-24 23:21





Seitdem haben wir Veeam ONE installiert, was ein wenig Licht in unsere Leistungsprobleme gebracht hat. Betrachten Sie den Bildschirm CPU Bottlenecks in Veeam ONE und verwenden Sie dann Problembehandlung bei einer virtuellen Maschine, die nicht mehr reagiert: Vergleich der VMM- und Gast-CPU-Auslastung Als Referenz haben wir herausgefunden, wo unsere "inakzeptable" Behauptung liegt.

Ein kleiner Tipp, den ich speziell teilen möchte, ist, dass ich in einem Fall CPU-Konflikte nicht beseitigen konnte, bis ich den Snapshot entfernt hatte, der auf der VM war. Hoffe, das hilft jemandem.


1
2018-04-28 14:53



Oh mein. Es liefen auch Schnappschüsse? - ewwhite