CPU-fähig: Der Silent Hypervisor Killer
Um zu verstehen, was CPU Ready ist, müssen wir verstehen, wie Hypervisoren virtuelle CPUs (vCPU) zu physischen CPUs (pCPU) einplanen. Wenn in einer VM vCPU-Zeit benötigt wird, müssen die vCPUs für pCPUs geplant werden, damit die Befehle / Prozesse / Threads für die pCPU ausgeführt werden können. In einer idealen Welt gibt es keine Ressourcenkonflikte oder Engpässe, wenn dies geschehen muss. Wenn eine einzelne vCPU-VM Zeit für eine pCPU einplanen muss, ist ein pCPU-Kern verfügbar und die CPU-Bereitschaft ist in dieser idealen Welt sehr gering. Es ist wichtig zu beachten, dass CPU Ready immer vorhanden ist, aber in einer idealen Welt ist es sehr minimal und wird nicht bemerkt.
In der realen Welt besteht einer der Vorteile der Virtualisierung darin, dass Sie darauf wetten können, dass viele Ihrer VMs nicht alle vCPUs gleichzeitig spitzen. Wenn es sich um VMs mit sehr geringer Auslastung handelt, können Sie sogar raten, wie viel Sie können Laden Sie Ihren physischen Host basierend auf der CPU-Auslastung und der RAM-Auslastung. In der Vergangenheit wurden Empfehlungen für ein Verhältnis von 4 vCPU zu 1 pCPU oder sogar 10: 1 je nach Arbeitsbelastung gegeben. Beispielsweise können Sie einen einzelnen Quad-Core-Prozessor haben, aber 4 VMs mit jeweils vCPUs, um 16 vCPUs zu 4 pCPUs oder 4: 1 zu erhalten. Die Ingenieure stellten jedoch fest, dass die Umgebungen nur sehr langsam waren und sie nicht herausfinden konnten, warum. Die RAM-Auslastung schien in Ordnung zu sein, die CPU-Auslastung auf den physischen Hosts kann mit unter 20% sogar sehr gering sein. Die Speicherlatenz war extrem gering, aber die VMs waren extrem träge.
In diesem Szenario war CPU Ready. Es gab eine Warteschlange für die vCPU, die zur Planung bereit war, für die jedoch keine pCPU zum Planen verfügbar war. Der Hypervisor würde die Planung blockieren und eine Latenz für die Gast-VM verursachen. Es ist ein stiller Mörder, dass bis in die letzten Jahre nicht viele Werkzeuge zu entdecken waren. In einer Windows-VM würde das Booten ewig dauern, und wenn Sie es schließlich tun, wenn Sie auf das Startmenü klicken, würde es ewig dauern, bis es angezeigt wird. Sie können sogar erneut darauf klicken, weil Sie glauben, dass es Ihren ersten Klick nicht akzeptiert hat, und wenn es endlich aufholt, erhalten Sie einen Doppelklick. Unter Linux startet Ihre VM möglicherweise in den schreibgeschützten Modus oder schaltet die Dateisysteme zu einem späteren Zeitpunkt sogar in den schreibgeschützten Modus.
Wie bekämpfen wir CPU Ready? Es gibt einige Möglichkeiten, die helfen können. Zunächst wird die CPU-fähige Metrik überwacht. In VMware wird nicht empfohlen, mehr als 10% zu verwenden. Aus persönlicher Erfahrung bemerken Benutzer jedoch, dass je nach VM-Typ und Ausführung mehr als 5-7% auftreten.
Im Folgenden werde ich einige Beispiele aus VMware ESXi 5.5 verwenden, um die CPU-Bereitschaft anzuzeigen. Führen Sie über die Befehlszeile “esxtop” aus. Drücken Sie “c” für die CPU-Ansicht und Sie sollten eine Spalte “sehen”% RDY”Für CPU Ready. Sie können Kapital drücken “V.”Für die Ansicht Nur VM.
Hier können Sie sehen, dass% RDY für eine ziemlich unbenutzte Umgebung etwas hoch ist. In diesem Fall führt mein ESXi 5.5 eine Test-VM auf VMware Fusion (Mac-Hypervisor) aus, sodass davon ausgegangen wird, dass sie etwas im oberen Preissegment liegt, da wir eine VM auf einem Hypervisor auf einem anderen Hypervisor ausführen.
Im vSphere-Client können Sie die jeweilige VM aufrufen und auf die Registerkarte Leistung klicken. Von dort aus klicken Sie auf die “Diagrammoptionen”
Wählen Sie unter Diagrammoptionen CPU, Echtzeit aus (wenn Sie über vCenter verfügen, haben Sie möglicherweise andere Timing-Optionen als Echtzeit). Wählen Sie dort in den Zählern “Bereit”. Möglicherweise müssen Sie die Auswahl eines anderen Zählers aufheben, da in der Ansicht jeweils nur zwei Datentypen zulässig sind.
Sie werden feststellen, dass dieser Wert eine Zusammenfassung von Bereit gegenüber einem Prozentsatz ist. Hier ist ein Link zu einem VMware KB-Artikel zum Konvertieren der zusammengefassten Metriken in einen Prozentsatz. – – https://kb.vmware.com/kb/2002181
Beim Kauf von Hardware tragen mehr Kerne dazu bei, die Auswirkungen von CPU Ready zu verringern. Hyperthreading hilft auch. Während Hyperthreading nicht für jeden primären Kern einen vollständigen zweiten Kern bereitstellt, reicht es normalerweise aus, die vCPU auf pCPU zu planen und das Problem zu mindern. Obwohl sich Hypervisoren allmählich von der Empfehlung für das Verhältnis von vCPU zu pCPU entfernen, können Sie in einer mäßig genutzten Umgebung mit 4: 1 in der Regel gut abschneiden und von dort aus fortfahren. Wenn Sie mit dem Laden von VMs beginnen, überprüfen Sie die CPU-Latenz, die CPU-Bereitschaft sowie das allgemeine Gefühl und die Leistung. Wenn Sie einige stark betroffene VMs haben, möchten Sie diese möglicherweise auf andere Cluster aufteilen und ein niedrigeres Verhältnis verwenden, um sie leicht zu halten. Auf der anderen Seite können Sie für VMs, bei denen die Leistung nicht entscheidend ist und die nur schleppend ausgeführt werden können, viel höher abonnieren.
Die richtige Dimensionierung der VMs ist auch ein großes Werkzeug zur Bekämpfung der CPU-Bereitschaft. Viele Anbieter empfehlen Spezifikationen, die weit über den tatsächlichen Anforderungen der VM liegen. Traditionell mehr CPUs und mehr Kerne = mehr Leistung. Das Problem in einer virtuellen Umgebung besteht darin, dass der Hypervisor alle vCPUs ungefähr zur gleichen Zeit auf pCPUs einplanen muss und das Sperren der pCPUs problematisch sein kann. Wenn Sie über eine 8-vCPU-VM verfügen, müssen Sie 8 pCPUs sperren, damit sie gleichzeitig planen können. Wenn Ihre vCPU-VM zu einem bestimmten Zeitpunkt nur 10% der gesamten vCPUs verwendet, ist es besser, die vCPU-Anzahl auf 2 oder 4 zu senken. Es ist besser, eine VM mit 50-80% CPU mit weniger vCPUs als mit 10% zu betreiben mehr vCPUs. Dieses Problem ist teilweise darauf zurückzuführen, dass der CPU-Scheduler des Betriebssystems so konzipiert ist, dass möglichst viele Kerne verwendet werden. Wenn er jedoch darauf trainiert wurde, die Anzahl der Kerne zu maximieren, bevor mehr verwendet werden, ist dies möglicherweise weniger problematisch. Eine übergroße VM kann eine gute Leistung erbringen, ist jedoch möglicherweise ein „verrauschter Nachbar“ für andere VMs. Daher müssen Sie normalerweise alle VMs im Cluster durchlaufen, um sie auf die richtige Größe zu bringen, um einige Leistungssteigerungen zu erzielen.
Oft sind Sie auf CPU Ready gestoßen, und es ist schwierig, mit der richtigen Dimensionierung von VMs oder dem Upgrade auf Prozessoren mit mehr Kernen zu beginnen. Wenn Sie sich in dieser Situation befinden, kann das Hinzufügen weiterer Hosts in Ihrem Cluster dabei helfen, die Last auf mehrere Hosts zu verteilen. Wenn Sie Hosts mit mehr Kernen / Prozessoren als andere haben, kann es auch hilfreich sein, hohe vCPU-VMs an diese Hosts mit höherem Kern zu binden. Sie möchten sicherstellen, dass Ihr physischer Host mindestens die gleiche Anzahl von Kernen hat, wenn nicht mehr als die VM. Andernfalls ist es sehr langsam / schwierig, den Überschuss von vCPU zu pCPU zu planen, da diese ungefähr zur gleichen Zeit gesperrt werden müssen .
Schließlich unterstützt Ihr Hypervisor möglicherweise Reservierungen und Einschränkungen für die VM. Manchmal werden Thesen versehentlich gesetzt. Aggressive Einstellungen auf diesen können dazu führen, dass die CPU bereit ist, wenn tatsächlich die zugrunde liegenden Ressourcen dafür verfügbar sind. Es ist normalerweise am besten, Reservierungen und Limits sparsam und nur dann zu verwenden, wenn dies unbedingt erforderlich ist. In den meisten Fällen wird ein Cluster mit der richtigen Größe die Ressourcen angemessen ausgleichen, und diese werden normalerweise nicht benötigt.
Zusammenfassend lässt sich sagen, dass die beste Verteidigung gegen CPU Ready darin besteht, zu wissen, dass es vorhanden ist und wie man es überprüft. Anschließend können Sie systematisch die besten Minderungsschritte für Ihre Umgebung ermitteln. Die Informationen in diesem Artikel gelten größtenteils universell für jeden Hypervisor, obwohl die Screenshots und Diagramme speziell für VMware gelten.
