Erweiterte VMware-Leistungswerte – Teil 1: CPU-Ready

Verfasst am 5. Apr. 2013 von | Kategorie: Server-Virtualisierung

Nur weil bestimmte Leistungsdaten in einer vSphere-Umgebung nicht auf den ersten Blick einzusehen sind, bedeutet das nicht, dass diese weniger wichtig sind. Teilweise ist sogar genau das Gegenteil der Fall. Viele Anwender glauben beispielsweise, dass sie keine CPU-Probleme haben können, wenn ihre Hostübersicht im vSphere Client so aussieht:

1_Übersicht

Falls Sie auch davon überzeugt sind, möchte ich Ihnen diesen Artikel sehr ans Herz legen.

Was bedeutet der Wert CPU-Ready (ms)?

Bei dieser Angabe handelt es sich um die Zeit, welche eine vCPU im CPU-Scheduler wartet, bis sie von einer physikalischen CPU bedient wird. Man kann sich daher vorstellen, dass ein hoher Wert an dieser Stelle schlecht ist.

Was verursacht hohe CPU-Ready-Werte?

1. CPU-Überbuchung

Hiermit ist gemeint, dass zu viele vCPUs auf eine physikalische CPU kommen. Selbstverständlich zielt man bei der Virtualisierung auf eine gewisse Überbuchung, um die gewünschte Effizienz der Umgebung zu erreichen. Aber das Ganze hat auch seine Grenzen. Unsere Erfahrungen zeigen folgende Ergebnisse für das Verhältnis von CPU zu vCPUs: – 1:1 bis 1:3 -> meist problemlos – 1:3 bis 1:5 -> Probleme können je nach Workload auftreten – Über 1:5 -> führt sehr häufig zu Problemen Die Auswirkungen und deren Umfang sind von den Anwendungen abhängig. Terminal Server zum Beispiel sollten nicht in einer Umgebung mit einer Überbuchung von mehr als 1:3 betrieben werden. Citrix selbst möchte sogar überhaupt keine Überbuchung.

Beispiel für eine Kalkulation der Überbuchung:

Vorhandene CPU-Ressourcen:

2_CPU-Ressourcen

Belegte vCPUs:

3_belegte-vCPUs

Rechenbeispiel: 32 logische CPUs für 42 vCPUs = 32:42 -> 1:1,3 -> sehr gutes Ansprechverhalten der vSphere-Umgebung zu erwarten

2. CPU-Limits

Allgemein sollen CPU-Limits nur in sehr speziellen Fällen zum Einsatz kommen. Im Normalfall haben Limits im CPU-Bereich negative Auswirkungen auf die Gesamt-Performance. Grund hierfür ist, dass eine vCPU rechnen möchte, wegen einer Verletzung des CPU-Limits aber nicht bearbeitet wird (bzw. nicht in den CPU-Scheduler gestellt wird). Die Indikatoren hierfür sind allerdings nicht im vSphere Client ersichtlich. Mit ESXTOP (CLI) können diese ausgelesen werden. Der Wert nennt sich %MLMTD (muss im Normalfall bei 0% liegen).

Beispiel für CPU-Limit

4_CPU-Limit

3. CPU-Affinity

Auch das ist etwas, was nur in sehr seltenen Fällen zum Einsatz kommt. Meist nur für Tests. Mit vSphere 5.1 und aktiviertem DRS steht diese Option gar nicht mehr zur Verfügung!

Einige Missverständnisse:

  • VMware behandelt die logischen CPUs eines Servers mit Hyper-Threading wie einen „echten“ CPU-Kern. Allerdings stellt der Core in diesem Fall nicht die volle Leitung, sondern nur ca. 75% zur Verfügung.
    Man sollte daher sehr konservativ mit der Kalkulation der Überbuchung sein.
  • Eine hohe Anzahl von GHz per Core hilft Ihnen nicht bei CPU-Ready-Problemen.
  • DRS hilft Ihnen nicht bei der Behebung, bzw. Vermeidung von CPU-Ready-Problemen.

Wie können Sie die relevanten Werte einsehen?

Am interessantesten sind die Werte pro VM im vSphere Client.

Betroffene VM > Leistung > Erweitert > Diagrammoptionen > folgende Auswahl:

5_Leistungswerte-CPU-Ready

Leistungswerte sehen dann wie folgt aus:

6_Grafik-CPU-Ready

Wichtig hierbei ist, dass die in der Grafik rot markierte Zeile die Gesamtzeiten aller vCPUs der VM darstellt. Dieser Wert ist also auch von der Anzahl der vCPUs anhängig.   Sich auf Hostebene einen Überblick per vSphere Client zu verschaffen, ist nahezu nicht möglich, da auf Hostebene immer die Summe aller CPU-Ready-Werte angezeigt wird. Möchten Sie sich dennoch einen schnellen Überblich verschaffen, ist ESXTOP das Mittel der Wahl:

7_ESXTOP

Sie sehen hier eine andere Kalkulationsart %RDY. Die Erklärung dazu finden Sie im nächsten Abschnitt. Diese Werte sind allerdings ebenfalls von der Anzahl der vCPUs der VM beeinflusst!

Welche Werte sind als kritisch anzusehen?

Am einfachsten ist dies in „ms“ auszudrücken, da diese Metrik im vSphere Client verwendet wird. VMware und auch wir sehen 1000ms pro vCPU für die meisten Applikationen als kritisch an. In einigen Dokumenten ist auch zu lesen, dass 5% CPU-Ready pro vCPU nicht zu überschreiten sind. Wie dieser Wert zu verstehen ist, erläutere ich an einem Beispiel: Vorab muss man dazu wissen, dass die VMware-Graphen auf 20 Sekunden-Samples basieren.

8_Legende

Daraus ergibt sich dann folgende Kalkulation: 44ms / 20000ms = 0,0022 oder %RDY = 0,22   Der angesprochene 1000ms Grenzwert würden dann so aussehen: 1000ms / 20000ms = 0,05 oder %RDY = 5,00   Somit ist dann klar, dass sich die beiden Aussagen (ms und %) decken.   Hier auch noch der Auszug zu diesem Thema aus dem VMware Performance Troubleshooting Guide:

Check for Ready Timea. Select a VM, then the Performance tab, then Advanced, then Switch to: CPUb. Look at the measurement Ready for all objects. In this case, the objects represent the vCPU numbers               for the VM. You may need to Change Chart Options in order to view the Ready measurement.c. Are there any periods when the Ready measurement was greater than 1000ms for any vCPU object? § Yes: VMs accumulated CPU Ready Time even though the host was not CPU saturated.Go to CPU-Related Performance Problems, for a discussion of possible causes and solutions.§ No: VMs did not accumulate CPU Ready Time. Return to the Basic Troubleshooting flow.d. Repeat steps b and c for all the VMs on the host

Ich möchte an dieser Stelle noch anfügen, dass die von VMware vorgegebenen Grenzwerte je nach Applikation variieren können. Gemeint ist damit, dass manche Anwendungen sehr gut mit hohen CPU-Ready-Werten umgehen können. Andere, vor allem sehr CPU-intensive Workloads können schon bei niedrigeren CPU-Ready-Werten Probleme bekommen. Bestes Beispiel hierfür sind wieder Terminal Server.

Was können Sie gegen hohe CPU-Ready-Werte unternehmen?

  • VMs korrekt dimensionierenSie sollten also nicht pauschal jeder VM zwei oder mehr vCPUs zuweisen, sondern erst einmal klein beginnen und dann die Last beobachten.
  • Keine CPU-Limits verwenden
  • Keine CPU-Affinity verwenden
  • Dem Cluster mehr physikalische CPUs hinzufügen

Eine mögliche Lösung ist auf jeden Fall, weitere Server hinzuzufügen bzw. die vorhandenen Server gegen größere auszutauschen

Wie können Sie überdimensionierte VMs erkennen?

Der einfachste Weg führt wieder über die Leistungsdaten auf VM-Ebene im vSphere Client. Betroffene VM > Leistung > Erweitert > Diagrammoptionen > folgende Auswahl:

9_Leistungswerte-CPU-MHz

Das Diagramm sollte dann so aussehen:

10_Grafik-CPU-MHz

Wir können in dem Diagramm nun zwei Dinge erkennen:

  • Die VM hat zwei vCPUs.
  • Eine vCPU ist meist unterfordert.

-> Eine Reduzierung auf eine vCPU sollte keine negativen Auswirkungen auf die Performance der VM haben. Noch ein kleiner Hinweis: Wenn Sie eine „VMware vSphere Enterprise Plus“ Lizenz besitzen, können Sie bei Ihren VMs folgende Optionen aktivieren:

11_hotAdd

Somit können Sie sehr schnell und ohne Downtime auf Engpässe reagieren.

Wie können Sie sich über Probleme mit hohen CPU-Ready-Werten benachrichtigen lassen?

In der Standard-Konfiguration alarmiert Sie das vCenter bei solchen Problemen nicht. Sie können aber natürlich selbst einen Alarm und eine Benachrichtigung hierfür anlegen. Hier meine Empfehlung für das Vorgehen:

1. Gruppieren Sie kritische VMs nach Anzahl der vCPUs in der Ansicht „VMs und Vorlagen“.

12_Alarm-1

2. Legen Sie einen neuen Alarm für den neuen Ordner an.

12_Alarm-2                             12_Alarm-3                             12_Alarm-4

Die Alarme werden dann auf Ebene der betroffenen VM direkt angezeigt und eine Mail wird automatisch versendet, wenn dies so konfiguriert ist.

Summary

Ich hoffe, ich konnte Ihnen einen guten Einblick liefern, welche „versteckten“ Probleme mit den erweiterten Leistungsdaten eines ESXi aufgedeckt werden können. Da das bei weiten noch nicht alles war, wird es hier noch einige Artikel rund um die erweiterten Leistungsdaten geben.

in den nächsten Artikeln würde ich gerne auf ein paar Spezialitäten von Arbeitsspeicher und Datenspeichern eingeben.  Wenn Sie hierzu Anregungen haben, freue ich mich sehr darüber.

Tags: , ,

Unser Newsletter informiert Sie über neue Beiträge in unserem Blog.

Ihre E-Mailadresse:

Hinterlassen Sie einen Kommentar!


zwei + 2 =