{"id":32331,"date":"2019-10-31T21:46:24","date_gmt":"2019-10-31T18:46:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\/"},"modified":"2019-10-31T21:46:24","modified_gmt":"2019-10-31T18:46:24","slug":"steal-kto-kradyot-u-virtualok-protsessornoe-vremya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","title":{"rendered":"Steal: wer stiehlt der Virtualisierung Prozessorzeit","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Steal: wer stiehlt der Virtualisierung Prozessorzeit\" src=\"\/wp-content\/uploads\/2019\/04\/23cac5d3cc3295dc6f1014e9fda36b89.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHallo! Ich m\u00f6chte in einfacher Sprache \u00fcber die Mechanik des CPU-Steals innerhalb von virtuellen Maschinen und einige weniger offensichtliche Artefakte sprechen, die wir bei unserer Untersuchung herausgefunden haben, in die ich als technischer Direktor der Cloud-Plattform eintauchen musste. <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Mail.ru Cloud Solutions<\/a><\/noindex>. Die Plattform l\u00e4uft auf KVM.<\/p>\n<p>Die CPU-Steal-Zeit ist die Zeit, in der eine virtuelle Maschine keine CPU-Ressourcen f\u00fcr ihre Ausf\u00fchrung erh\u00e4lt. Diese Zeit wird nur in den Gast-Betriebssystemen in Virtualisierungsumgebungen erfasst. Die Gr\u00fcnde daf\u00fcr, wohin diese zugewiesenen Ressourcen verschwinden, sind, wie im echten Leben, recht vage. Aber wir haben beschlossen, das herauszufinden und eine Reihe von Experimenten durchzuf\u00fchren. Es ist nicht so, dass wir jetzt alles \u00fcber Steal wissen, aber wir werden dir etwas Interessantes erz\u00e4hlen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>1. Was ist Steal<\/h2>\n<p>\nAlso, Steal ist eine Kennzahl, die auf den Mangel an CPU-Zeit f\u00fcr Prozesse innerhalb der virtuellen Maschine hinweist. Wie beschrieben <noindex><a rel=\"nofollow\" href=\"https:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/stable\/linux.git\/patch\/?id=c9aaa8957f203bd6df83b002fb40b98390bed078\">in dem KVM-Kernel-Patch<\/a><\/noindex>, ist Steal die Zeit, w\u00e4hrend der der Hypervisor andere Prozesse auf dem Host-Betriebssystem ausf\u00fchrt, obwohl er den Prozess der virtuellen Maschine zum Ausf\u00fchren in die Warteschlange gestellt hat. Das hei\u00dft, Steal wird als die Differenz zwischen der Zeit, in der der Prozess bereit zur Ausf\u00fchrung ist, und der Zeit, zu der dem Prozess CPU-Zeit zugewiesen wird, betrachtet.<\/p>\n<p>Die Steal-Kennzahl erh\u00e4lt die virtuelle Maschine vom Hypervisor. Der Hypervisor gibt dabei jedoch nicht an, welche anderen Prozesse er ausf\u00fchrt; er sagt einfach: \u201eIch kann dir keine Zeit widmen, da ich besch\u00e4ftigt bin\u201c. Auf KVM wurde die Unterst\u00fctzung zur Berechnung von Steal in <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/449657\/\">Patches<\/a><\/noindex>. Hier gibt es zwei entscheidende Punkte: <\/p>\n<ul>\n<li>Die virtuelle Maschine erf\u00e4hrt von Steal durch den Hypervisor. Das hei\u00dft, aus Sicht der Verluste ist es f\u00fcr die Prozesse in der virtuellen Maschine eine indirekte Messung, die verschiedenen Verzerrungen unterliegen kann.\n<\/li>\n<li>Der Hypervisor teilt der virtuellen Maschine keine Informationen dar\u00fcber mit, womit er sonst besch\u00e4ftigt ist \u2013 das Hauptsache ist, dass er ihr keine Zeit widmet. Dadurch kann die virtuelle Maschine selbst keine Verzerrungen in der Steal-Kennzahl feststellen, die man anhand der Art der konkurrierenden Prozesse bewerten k\u00f6nnte.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Was beeinflusst Steal<\/h2>\n<p><\/p>\n<h3>2.1. Berechnung von Steal<\/h3>\n<p>\nIm Grunde genommen wird Steal auf \u00e4hnliche Weise berechnet wie die gew\u00f6hnliche Auslastungszeit der CPU. Es gibt nicht viele Informationen dar\u00fcber, wie die Auslastung berechnet wird. Wahrscheinlich, weil die meisten diesen Aspekt f\u00fcr selbstverst\u00e4ndlich halten. Aber auch hier gibt es T\u00fccken. Um sich mit diesem Prozess vertraut zu machen, kann man lesen <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-05-09\/cpu-utilization-is-wrong.html\">Artikel von Brendann Gregg<\/a><\/noindex>: Sie erfahren eine Menge Details zur Berechnung der Auslastung und zu Situationen, in denen diese Berechnung aus folgenden Gr\u00fcnden fehlerhaft sein kann:<\/p>\n<ul>\n<li>\u00dcberhitzung des Prozessors, bei der Taktzyklen ausgelassen werden.\n<\/li>\n<li>Aktivierung\/Deaktivierung des Turbo-Boosts, wodurch sich die Taktfrequenz des Prozessors \u00e4ndert.\n<\/li>\n<li>\u00c4nderung der Zeitquantum-Dauer, die bei Verwendung von Energiespartechnologien des Prozessors auftritt, zum Beispiel SpeedStep.\n<\/li>\n<li>Das Problem bei der Durchschnittsberechnung: Eine Auslastung von 80 % \u00fcber eine Minute kann einen kurzen Burst von 100 % verbergen.\n<\/li>\n<li>Eine zyklische Sperre (spin lock) f\u00fchrt dazu, dass der Prozessor ausgelastet ist, der Benutzerprozess jedoch keine Fortschritte bei seiner Ausf\u00fchrung sieht. Infolgedessen wird die berechnete Auslastung des Prozessors durch den Prozess 100 % betragen, obwohl die physische Prozessorzeit vom Prozess nicht verbraucht wird.\n<\/li>\n<\/ul>\n<p>\nIch habe keinen Artikel gefunden, der eine \u00e4hnliche Berechnung f\u00fcr steal beschreibt (wenn Sie einen kennen, teilen Sie ihn bitte in den Kommentaren). Aber laut den Quellcodes ist der Berechnungsmechanismus derselbe wie f\u00fcr die Auslastung. Im Kern wird lediglich ein zus\u00e4tzlicher Z\u00e4hler hinzugef\u00fcgt, der direkt f\u00fcr den KVM-Prozess (Virtuelle Maschine) verantwortlich ist und die Dauer der Wartezeit des KVM-Prozesses auf die Prozessorzeit z\u00e4hlt. Der Z\u00e4hler bezieht seine Informationen \u00fcber den Prozessor aus dessen Spezifikation und pr\u00fcft, ob alle seine Taktzyklen vom Virtuellen Prozess genutzt wurden. Falls ja, gehen wir davon aus, dass der Prozessor nur mit dem virtuellen Maschinenprozess besch\u00e4ftigt war. Andernfalls informieren wir dar\u00fcber, dass der Prozessor auch mit etwas anderem besch\u00e4ftigt war, es trat steal auf. <\/p>\n<p>Der Prozess zur Berechnung von steal ist denselben Problemen wie die gew\u00f6hnliche Auslastungsberechnung ausgesetzt. Man kann nicht sagen, dass solche Probleme h\u00e4ufig auftreten, aber sie sehen entmutigend aus.<\/p>\n<h3>2.2. Arten der Virtualisierung unter KVM<\/h3>\n<p>\nGenerell gibt es drei Arten der Virtualisierung, die alle von KVM unterst\u00fctzt werden. Die Art der Virtualisierung kann den Mechanismus f\u00fcr das Entstehen von steal beeinflussen.<\/p>\n<p><b>\u00dcbertragung<\/b>. In diesem Fall erfolgt die Interaktion des Betriebssystems der virtuellen Maschine mit den physikalischen Ger\u00e4ten des Hypervisors ungef\u00e4hr so:<\/p>\n<ol>\n<li>Das Gastbetriebssystem sendet einen Befehl an sein Gastger\u00e4t.\n<\/li>\n<li>Der Treiber des Gastger\u00e4ts empf\u00e4ngt den Befehl, erstellt eine Anfrage f\u00fcr das BIOS des Ger\u00e4ts und sendet sie an den Hypervisor.\n<\/li>\n<li>Der Hypervisor-Prozess \u00fcbersetzt den Befehl in einen Befehl f\u00fcr das physische Ger\u00e4t und macht ihn dadurch unter anderem sicherer.\n<\/li>\n<li>Der Treiber des physischen Ger\u00e4ts nimmt den modifizierten Befehl entgegen und sendet ihn an das physische Ger\u00e4t.\n<\/li>\n<li>Die Ergebnisse der Befehlsausf\u00fchrung gehen denselben Weg zur\u00fcck. \n<\/li>\n<\/ol>\n<p>\nDer Vorteil der \u00dcbersetzung besteht darin, dass sie erm\u00f6glicht, jedes Ger\u00e4t zu emulieren und keine spezielle Vorbereitung des Betriebssystemkerns erfordert. Daf\u00fcr muss man jedoch vor allem auf die Geschwindigkeit verzichten. <\/p>\n<p><b>Hardware-Virtualisierung<\/b>. In diesem Fall versteht das Ger\u00e4t auf physischer Ebene die Befehle des Betriebssystems. Dies ist der schnellste und beste Weg. Leider wird er jedoch nicht von allen physischen Ger\u00e4ten, Hypervisoren und Gastbetriebssystemen unterst\u00fctzt. Derzeit sind die Hauptger\u00e4te, die Hardware-Virtualisierung unterst\u00fctzen, Prozessoren.<\/p>\n<p><b>Paravirtualisierung (paravirtualization)<\/b>. Die am weitesten verbreitete Art der Ger\u00e4tevigilisierung auf KVM und \u00fcberhaupt der am weitesten verbreitete Virtualisierungsmodus f\u00fcr Gastbetriebssysteme. Sein Merkmal ist, dass die Arbeit mit bestimmten Hypervisor-Subsystemen (zum Beispiel mit dem Netzwerk- oder Festplattentreiber) oder die Zuweisung von Speicherseiten unter Verwendung der Hypervisor-API erfolgt, ohne dass niedrigstufige Befehle \u00fcbersetzt werden. Ein Nachteil dieser Virtualisierungsart ist die Notwendigkeit, den Kern des Gastbetriebssystems zu modifizieren, damit er \u00fcber diese API mit dem Hypervisor interagieren kann. Dies wird jedoch in der Regel durch die Installation spezieller Treiber im Gastbetriebssystem gel\u00f6st. In KVM wird diese API genannt <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/developerworks\/library\/l-virtio\/index.html\">virtio API<\/a><\/noindex>.<\/p>\n<p>Bei der Paravirtualisierung im Vergleich zur \u00dcbersetzung wird der Weg zum physischen Ger\u00e4t erheblich verk\u00fcrzt, indem die Befehle direkt aus der virtuellen Maschine an den Hypervisor-Prozess auf dem Host gesendet werden. Dies beschleunigt die Ausf\u00fchrung aller Anweisungen innerhalb der virtuellen Maschine. In KVM ist daf\u00fcr die virtio API verantwortlich, die nur f\u00fcr bestimmte Ger\u00e4te wie Netzwerk- oder Festplattentreiber funktioniert. Aus diesem Grund werden in die virtuellen Maschinen virtio-Treiber installiert. <\/p>\n<p>Die Kehrseite einer solchen Beschleunigung ist, dass nicht alle Prozesse, die innerhalb der virtuellen Maschine ausgef\u00fchrt werden, dort verbleiben. Dies erzeugt spezielle Effekte, die zu einem Auftreten bei steal f\u00fchren k\u00f6nnen. Eine detaillierte Untersuchung dieses Themas empfehle ich, zu beginnen mit <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/239238\/\">Eine API f\u00fcr virtuelles I\/O: virtio<\/a><\/noindex>.<\/p>\n<h3>2.3. \u201eGerechte\u201c Planung<\/h3>\n<p>\nEine virtuelle Maschine auf einem Hypervisor ist tats\u00e4chlich ein gew\u00f6hnlicher Prozess, der den Regeln der Planung (Ressourcenverteilung zwischen Prozessen) im Linux-Kernel unterliegt, daher betrachten wir ihn n\u00e4her. <\/p>\n<p>In Linux wird der sogenannte CFS, Completely Fair Scheduler, seit Kernel 2.6.23 als Standard-Dispatcher verwendet. Um diesen Algorithmus zu verstehen, kann man die Linux Kernel Architecture oder den Source Code lesen. Die Essenz des CFS besteht darin, die CPU-Zeit zwischen Prozessen in Abh\u00e4ngigkeit von der Dauer ihrer Ausf\u00fchrung zu verteilen. Je mehr CPU-Zeit ein Prozess ben\u00f6tigt, desto weniger Zeit erh\u00e4lt er. Dies garantiert eine \u201egerechte\u201c Ausf\u00fchrung aller Prozesse \u2014 damit ein Prozess nicht st\u00e4ndig alle Prozessoren belegt und auch andere Prozesse ausgef\u00fchrt werden k\u00f6nnen. <\/p>\n<p>Manchmal f\u00fchrt ein solches Paradigma zu interessanten Artefakten. Langj\u00e4hrige Linux-Nutzer erinnern sich sicherlich an das Einfrieren von normalen Texteditoren auf dem Desktop w\u00e4hrend des Starts ressourcenintensiver Anwendungen wie Compiler. Dies geschah, weil ressourcenunintensive Aufgaben von Desktop-Anwendungen mit ressourcenintensiven Aufgaben wie dem Compiler konkurrierten. CFS h\u00e4lt dies f\u00fcr unfair, weshalb es den Texteditor periodisch stoppt und der CPU erm\u00f6glicht, die Aufgaben des Compilers zu bearbeiten. Dies wurde durch einen Mechanismus korrigiert <noindex><a rel=\"nofollow\" href=\"https:\/\/marc.info\/?l=linux-kernel&amp;m=128978361700898\">sched_autogroup<\/a><\/noindex>, aber es blieben viele andere Besonderheiten bei der Verteilung der CPU-Zeit zwischen Aufgaben. Tats\u00e4chlich handelt es sich hierbei nicht um einen Bericht dar\u00fcber, wie schlecht alles beim CFS ist, sondern um den Versuch, auf die Tatsache aufmerksam zu machen, dass die \u201egerechte\u201c Verteilung der CPU-Zeit keine triviale Aufgabe ist.<\/p>\n<p>Ein weiterer wichtiger Punkt im Scheduler ist die Preemption. Dies ist notwendig, um einen \u00fcberlasteten Prozess vom Prozessor zu entfernen und anderen Prozessen die M\u00f6glichkeit zu geben, zu arbeiten. Der Prozess des Entfernens wird als Kontextwechsel bezeichnet, wobei der Kontext des Tasks wie der Stack-Zustand, Register und anderes erhalten bleibt, bevor der Prozess zum Warten geschickt wird und ein anderer an seine Stelle tritt. Dies ist eine kostspielige Operation f\u00fcr das Betriebssystem und wird selten verwendet, aber grunds\u00e4tzlich ist daran nichts Schlechtes. H\u00e4ufige Kontextwechsel k\u00f6nnen auf ein Problem im Betriebssystem hinweisen, aber normalerweise verlaufen sie kontinuierlich und deuten auf nichts Besonderes hin.<\/p>\n<p>Diese ausf\u00fchrliche Erkl\u00e4rung ist n\u00f6tig, um einen Fakt zu verdeutlichen: Je mehr Ressourcen der Prozessor von einem Prozess in einem fairen Scheduler von Linux zu beanspruchen versucht, desto schneller wird dieser gestoppt, damit auch andere Prozesse arbeiten k\u00f6nnen. Ob dies richtig oder falsch ist, ist eine komplexe Frage, die unter verschiedenen Lasten unterschiedlich beantwortet wird. Bis vor kurzem war der Scheduler in Windows auf die priorisierte Verarbeitung von Desktop-Anwendungen ausgerichtet, wodurch Hintergrundprozesse zum Einfrieren neigten. In Sun Solaris gab es f\u00fcnf verschiedene Klassen von Schedulern. Als die Virtualisierung eingef\u00fchrt wurde, wurde die sechste hinzugef\u00fcgt, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opennet.ru\/man.shtml?topic=FSS&amp;category=7&amp;russian=4\">Fair Share Scheduler<\/a><\/noindex>, weil die vorherigen f\u00fcnf mit der Virtualisierung der Solaris Zones unangemessen arbeiteten. Eine detaillierte Untersuchung dieses Themas empfehle ich Ihnen, mit B\u00fcchern wie <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Solaris-Internals-OpenSolaris-Kernel-Architecture\/dp\/0131482092\/\">Solaris Internals: Solaris 10 und OpenSolaris Kernel-Architektur<\/a><\/noindex> oder <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Understanding-Linux-Kernel-Third-Daniel\/dp\/0596005652\/\">Understanding the Linux Kernel<\/a><\/noindex>.<\/p>\n<h3>2.4. Wie kann man Steal \u00fcberwachen?<\/h3>\n<p>\nSteal innerhalb einer virtuellen Maschine zu \u00fcberwachen, ist wie jede andere prozessorgest\u00fctzte Metrik einfach: Sie k\u00f6nnen jedes Metrik-Sammeltool f\u00fcr Prozessoren verwenden. Das Wichtigste ist, dass die virtuelle Maschine unter Linux l\u00e4uft. Windows stellt aus irgendeinem Grund diese Informationen seinen Benutzern nicht zur Verf\u00fcgung. \ud83d\ude41<\/p>\n<p><img decoding=\"async\" alt=\"Steal: wer stiehlt der Virtualisierung Prozessorzeit\" src=\"\/wp-content\/uploads\/2019\/04\/3c7cd04f73fd6a74b86af81382090b69.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ausgabe des Befehls top: Detaillierung der Prozessorlast, in der \u00e4u\u00dfersten rechten Spalte \u2014 Steal<\/i><\/p>\n<p>Die Schwierigkeit tritt auf, wenn man versucht, diese Informationen vom Hypervisor zu erhalten. Man kann versuchen, den Steal auf der Hostmaschine zu prognostizieren, beispielsweise anhand des Parameters Load Average (LA) \u2014 eines durchschnittlichen Wertes der Anzahl von Prozessen, die in der Warteschlange auf die Ausf\u00fchrung warten. Die Berechnungsmethode dieses Parameters ist nicht einfach, aber im Allgemeinen, wenn der auf die Anzahl der Prozessor-Threads normierte LA gr\u00f6\u00dfer als 1 ist, deutet dies darauf hin, dass der Server mit Linux aus irgendeinem Grund \u00fcberlastet ist. <\/p>\n<p>Was erwarten all diese Prozesse? Die offensichtliche Antwort ist der Prozessor. Aber die Antwort ist nicht ganz korrekt, denn manchmal ist der Prozessor frei, w\u00e4hrend die LA \u00fcbersteigt. Denken Sie daran, <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/911976\/redhat-nfs-cluster-high-load-average-suddenly\">wie NFS ausf\u00e4llt und dabei die LA steigt.<\/a><\/noindex>\u00c4hnlich kann es auch mit Festplatten und anderen Ein-\/Ausgabeger\u00e4ten sein. Tats\u00e4chlich k\u00f6nnen Prozesse auf das Ende jeglicher Sperre warten, sei es eine physikalische, die mit dem Ein-\/Ausgabeger\u00e4t verbunden ist, oder eine logische, wie beispielsweise ein Mutex. Dazu geh\u00f6ren auch Sperren auf Hardware-Ebene (wie die Antwort von der Festplatte) oder auf der logischen Ebene (die sogenannten Sperrprimitive, die viele Entit\u00e4ten umfasst, wie adaptive Mutexes und Spinlocks, Semaphore, Bedingungsvariablen, rw Locks, ipc Locks\u2026).<\/p>\n<p>Ein weiteres Merkmal von LA ist, dass es als Durchschnittswert im Betriebssystem betrachtet wird. Zum Beispiel, wenn 100 Prozesse um eine Datei konkurrieren, dann ist LA=50. So ein hoher Wert k\u00f6nnte darauf hindeuten, dass das Betriebssystem Schwierigkeiten hat. Aber f\u00fcr gewisserma\u00dfen schlecht geschriebene Codes kann das ein normales Zustand sein, wobei nur dieser Prozess betroffen ist und andere Prozesse im Betriebssystem nicht leiden. <\/p>\n<p>Wegen dieser Mittelwertbildung (in der Regel \u00fcber mindestens eine Minute) ist es nicht gerade einfach, irgendetwas anhand der LA-Messung zu bestimmen \u2014 die Ergebnisse in bestimmten F\u00e4llen sind eher unklar. Wenn Sie versuchen, das herauszufinden, werden Sie feststellen, dass in Wikipedia-Artikeln und anderen verf\u00fcgbaren Ressourcen nur die einfachsten F\u00e4lle beschrieben werden, ohne tiefere Erkl\u00e4rungen des Prozesses. Alle Interessierten verweise ich daher erneut <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-08-08\/linux-load-averages.html\">hierhin, zu Brendann Gregg<\/a><\/noindex> \u00a0\u2014 weiter \u00fcber die Links. Wer sich auf Englisch nicht wohlf\u00fchlt \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/335326\/\">die \u00dcbersetzung seines beliebten Artikels \u00fcber LA<\/a><\/noindex>.<\/p>\n<h2>3. Spezialeffekte<\/h2>\n<p>\nJetzt wollen wir uns mit den Hauptf\u00e4llen von Steal befassen, die wir erlebt haben. Ich werde erkl\u00e4ren, wie sie aus dem oben Gesagten hervorgehen und wie sie sich auf die Metriken im Hypervisor beziehen.<\/p>\n<p><b>Re-Utilisierung<\/b>. Das Einfachste und H\u00e4ufigste: Der Hypervisor ist \u00fcberlastet. Tats\u00e4chlich gibt es viele gestartete virtuelle Maschinen, einen hohen CPU-Verbrauch innerhalb dieser, gro\u00dfe Konkurrenz, eine LA-Utilisierung von \u00fcber 1 (normiert auf die Prozessorthreads). Innerhalb der virtuellen Maschinen l\u00e4uft alles langsam. Der Steal, der vom Hypervisor \u00fcbertragen wird, steigt ebenfalls an, und es ist notwendig, die Last neu zu verteilen oder jemanden auszuschalten. Insgesamt ist das alles logisch und verst\u00e4ndlich.<\/p>\n<p><b>Paravirtualisierung vs. einzelne Instanzen<\/b>. Auf dem Hypervisor gibt es eine einzige virtuelle Maschine, die einen kleinen Teil davon konsumiert, aber eine hohe Last beim Ein- und Ausgeben erzeugt, zum Beispiel beim Speicher. Und irgendwo in ihr erscheint ein kleiner Steal, bis zu 10 % (wie mehrere durchgef\u00fchrte Experimente zeigen).<\/p>\n<p>Ein interessanter Fall. Der Steal entsteht hier gerade wegen der Sperren auf der Ebene der paravirtualisierten Treiber. Innerhalb der virtuellen Maschine entsteht eine Unterbrechung, die vom Treiber verarbeitet wird und zum Hypervisor geht. Wegen der Unterbrechungsverarbeitung auf dem Hypervisor sieht es f\u00fcr die virtuelle Maschine so aus, als w\u00e4re eine Anfrage gesendet worden; sie ist bereit zur Ausf\u00fchrung und wartet auf die CPU, aber ihr wird keine Prozessorzeit gegeben. Die virtuelle Maschine denkt, diese Zeit sei gestohlen. <\/p>\n<p>Dies geschieht im Moment des Sendens eines Puffers, der in den Kernel-Space des Hypervisors geht, und wir beginnen darauf zu warten. Obwohl aus der Sicht der virtuellen Maschine dieser sofort zur\u00fcckkommen sollte. Folglich wird laut dem Algorithmus zur Berechnung des Steals diese Zeit als gestohlen angesehen. Wahrscheinlich gibt es in dieser Situation auch andere Mechanismen (zum Beispiel die Verarbeitung anderer Systemaufrufe), aber sie sollten sich nicht stark unterscheiden.<\/p>\n<p><b>Scheduler gegen stark belastete virtuelle Maschinen<\/b>. Wenn eine virtuelle Maschine mehr unter Steal leidet als andere, h\u00e4ngt das genau mit dem Scheduler zusammen. Je st\u00e4rker ein Prozess die CPU belastet, desto schneller wird ihn der Scheduler herauswerfen, damit auch die anderen arbeiten k\u00f6nnen. Wenn die virtuelle Maschine wenig konsumiert, wird sie Steal kaum bemerken: Ihr Prozess hat brav gesessen und gewartet, ihm sollte mehr Zeit gegeben werden. Wenn die virtuelle Maschine die maximale Last \u00fcber alle ihre Kerne erzeugt, wird sie h\u00e4ufiger von der CPU geworfen und es wird versucht, ihr nicht viel Zeit zu geben. <\/p>\n<p>Es ist noch schlimmer, wenn Prozesse innerhalb der virtuellen Maschine versuchen, mehr CPU zu gewinnen, weil sie mit der Verarbeitung der Daten nicht zurechtkommen. Dann wird das Betriebssystem auf dem Hypervisor, durch ehrliche Optimierung, immer weniger Prozessorzeit gew\u00e4hren. Dieser Prozess geschieht lawinenartig, und der Steal schnellt in die H\u00f6he, w\u00e4hrend die anderen virtuellen Maschinen kaum etwas bemerken. Und je mehr Kerne, desto schlechter f\u00fcr die betroffene Maschine. Kurz gesagt, stark belastete virtuelle Maschinen mit vielen Kernen leiden am meisten.<\/p>\n<p><b>Niedriger LA, aber es gibt Steal<\/b>. Wenn der LA etwa 0,7 betr\u00e4gt (das hei\u00dft, der Hypervisor erscheint unterlastet), aber innerhalb einzelner virtueller Maschinen Steal beobachtet wird:<\/p>\n<ul>\n<li>Die bereits oben beschriebene Variante mit Paravirtualisierung. Die virtuelle Maschine kann Metriken erhalten, die auf Steals hinweisen, obwohl beim Hypervisor alles gut ist. Nach den Ergebnissen unserer Experimente \u00fcbersteigt ein solches Steal 10 % nicht und sollte keinen wesentlichen Einfluss auf die Leistung von Anwendungen innerhalb der virtuellen Maschine haben.\n<\/li>\n<li>Der Parameter LA wird falsch angesehen. Genauer gesagt, er wird zu jedem bestimmten Zeitpunkt korrekt betrachtet, aber bei der Durchschnittsbildung \u00fcber eine Minute wird er zu niedrig ausgewiesen. Wenn beispielsweise eine virtuelle Maschine ein Drittel des Hypervisors genau eine halbe Minute lang alle ihre Prozessoren beansprucht, betr\u00e4gt der LA f\u00fcr eine Minute beim Hypervisor 0,15; vier solcher virtuellen Maschinen, die gleichzeitig arbeiten, ergeben 0,6. Dass w\u00e4hrend dieser halben Minute bei jeder von ihnen ein drastischer Steal von 25 % im LA-Wert war, l\u00e4sst sich nicht mehr herausholen.\n<\/li>\n<li>Wieder einmal aufgrund desSchedulers, der entschieden hat, dass jemand zu viel frisst, und dieser jemand warten soll. W\u00e4hrend ich das Kontext wechsle, Unterbrechungen bearbeite und mich um andere wichtige Systemangelegenheiten k\u00fcmmere. Letztendlich sehen einige virtuelle Maschinen keine Probleme, w\u00e4hrend andere unter schwerer Leistungseinbu\u00dfe leiden.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>4. Andere Verzerrungen<\/h2>\n<p>\nEs gibt noch Millionen von Gr\u00fcnden f\u00fcr Verzerrungen in der fairen Zuteilung der Prozessorzeit in der virtuellen Maschine. Zum Beispiel f\u00fchren Hyper-Threading und NUMA zu Schwierigkeiten bei den Berechnungen. Sie verwirren die Auswahl des Kerns f\u00fcr die Ausf\u00fchrung eines Prozesses, da der Scheduler Gewichte verwendet, die die Berechnungen bei Kontextwechseln noch komplexer machen.<\/p>\n<p>Es k\u00f6nnen Verzerrungen durch Technologien wie Turbo-Boost oder umgekehrt durch Energiesparmodi auftreten, die bei der Berechnung der Auslastung k\u00fcnstlich die Frequenz oder sogar das Zeitquantum auf dem Server erh\u00f6hen oder senken k\u00f6nnen. Das Aktivieren von Turbo-Boost verringert die Leistung eines Prozessor-Threads aufgrund der erh\u00f6hten Leistung eines anderen. In diesem Moment wird der virtuellen Maschine keine aktuelle Frequenz des Prozessors \u00fcbermittelt, und sie glaubt, dass ihre Zeit gestohlen wird (zum Beispiel, sie hat 2 GHz angefordert, erh\u00e4lt aber nur die H\u00e4lfte). <\/p>\n<p>Insgesamt kann es viele Gr\u00fcnde f\u00fcr Verzerrungen geben. In einem bestimmten System k\u00f6nnen Sie noch etwas anderes entdecken. Beginnen Sie am besten mit den B\u00fcchern, auf die ich oben verwiesen habe, und der Erfassung von Statistiken vom Hypervisor mit Tools wie perf, sysdig, systemtap, von denen es <noindex><a rel=\"nofollow\" href=\"https:\/\/jvns.ca\/blog\/2017\/07\/05\/linux-tracing-systems\/\">Dutzende gibt<\/a><\/noindex>.<\/p>\n<h2>5. Fazit<\/h2>\n<p><\/p>\n<ol>\n<li>Eine gewisse Menge an Steal kann durch Paravirtualisierung entstehen und gilt als normal. Im Internet wird berichtet, dass dieser Wert zwischen 5 und 10 % liegen kann. Es h\u00e4ngt von den Anwendungen innerhalb der virtuellen Maschine und von der Last ab, die sie auf ihre physischen Ger\u00e4te aus\u00fcbt. Hier ist es wichtig, darauf zu achten, wie sich die Anwendungen innerhalb der virtuellen Maschinen verhalten.\n<\/li>\n<li>Das Verh\u00e4ltnis von Last auf dem Hypervisor und Steal innerhalb der virtuellen Maschine ist nicht immer eindeutig miteinander verbunden; beide Werte f\u00fcr Steal k\u00f6nnen in bestimmten Situationen bei unterschiedlichen Lasten fehlerhaft sein.\n<\/li>\n<li>Der Scheduler hat eine negative Einstellung gegen\u00fcber Prozessen, die viel anfordern. Er versucht, weniger Ressourcen an diejenigen zu vergeben, die mehr anfordern. Gro\u00dfe virtuelle Maschinen sind problematisch.\n<\/li>\n<li>Ein geringf\u00fcgiger Steal kann auch ohne Paravirtualisierung normal sein (unter Ber\u00fccksichtigung der Last innerhalb der virtuellen Maschine, der Besonderheiten der Lasten benachbarter Maschinen, der Verteilung der Last auf die Threads und anderer Faktoren).\n<\/li>\n<li>Wenn Sie den Steal in einem bestimmten System feststellen m\u00f6chten, m\u00fcssen verschiedene Optionen untersucht, Metriken gesammelt, sorgf\u00e4ltig analysiert und \u00dcberlegungen angestellt werden, wie die Last gleichm\u00e4\u00dfig verteilt werden kann. Abweichungen von jeglichen Szenarien m\u00fcssen experimentell best\u00e4tigt oder im Kernel-Debugger \u00fcberpr\u00fcft werden.\n<\/li>\n<\/ol>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/449316\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442! \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e\u0441\u0442\u044b\u043c \u044f\u0437\u044b\u043a\u043e\u043c \u043e \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0435 \u0432\u043e\u0437\u043d\u0438\u043a\u043d\u043e\u0432\u0435\u043d\u0438\u044f steal \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0438 \u043e \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043d\u0435\u043e\u0447\u0435\u0432\u0438\u0434\u043d\u044b\u0445 \u0430\u0440\u0442\u0435\u0444\u0430\u043a\u0442\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0430\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u0432\u044b\u044f\u0441\u043d\u0438\u0442\u044c \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0438, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u043c\u043d\u0435 \u043f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u043f\u043e\u0433\u0440\u0443\u0437\u0438\u0442\u044c\u0441\u044f \u043a\u0430\u043a \u0442\u0435\u0445\u0434\u0438\u0440\u0443 \u043e\u0431\u043b\u0430\u0447\u043d\u043e\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Mail.ru Cloud Solutions. \u041f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043d\u0430 KVM. CPU steal time \u2014 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f, \u0432 \u0442\u0435\u0447\u0435\u043d\u0438\u0435 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0430\u044f \u043c\u0430\u0448\u0438\u043d\u0430 \u043d\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442 \u0440\u0435\u0441\u0443\u0440\u0441\u044b \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24147,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32331","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Steal: \u043a\u0442\u043e \u043a\u0440\u0430\u0434\u0451\u0442 \u0443 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u043e\u043a \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:46:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:46:24+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Steal: Wer stiehlt der virtuellen Maschine CPU-Zeit | ProHoster","description":"Hallo!","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Steal: \u043a\u0442\u043e \u043a\u0440\u0430\u0434\u0451\u0442 \u0443 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u043e\u043a \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442!","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:46:24+00:00","article:modified_time":"2019-10-31T18:46:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32331","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 10:21:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:00:23","updated":"2026-01-21 10:21:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=32331"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/24147"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=32331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=32331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=32331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}