{"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\/nl\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","title":{"rendered":"Steal: wie steelt er CPU-tijd van virtuele machines","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Steal: wie steelt er CPU-tijd van virtuele machines\" src=\"\/wp-content\/uploads\/2019\/04\/23cac5d3cc3295dc6f1014e9fda36b89.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHallo! Ik wil op een eenvoudige manier uitleggen hoe steal binnen virtuele machines ontstaat en enkele onopvallende artefacten die we hebben ontdekt tijdens het onderzoek, waarin ik als technisch directeur van het cloudplatform moest duiken. <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Mail.ru Cloud Solutions<\/a><\/noindex>. Het platform draait op KVM.<\/p>\n<p>CPU steal time is de tijd waarin een virtuele machine geen CPU-middelen ontvangt voor zijn uitvoering. Deze tijd wordt alleen in gastbesturingssystemen in virtualisatieomgevingen geteld. De redenen waar deze toegewezen middelen naartoe gaan zijn, net als in het echte leven, vrij vaag. Maar we hebben besloten het uit te zoeken en hebben zelfs een reeks experimenten uitgevoerd. Niet dat we nu alles weten over steal, maar we zullen wel iets interessants vertellen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>1. Wat is steal<\/h2>\n<p>\nDus, steal is een metric die aangeeft dat er onvoldoende CPU-tijd is voor processen binnen de virtuele machine. Zoals beschreven <noindex><a rel=\"nofollow\" href=\"https:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/stable\/linux.git\/patch\/?id=c9aaa8957f203bd6df83b002fb40b98390bed078\">in de KVM-kernelpatch<\/a><\/noindex>, is steal de tijd waarin de hypervisor andere processen op het hostbesturingssysteem uitvoert, ook al heeft hij het proces van de virtuele machine in de wachtrij geplaatst voor uitvoering. Met andere woorden, steal wordt berekend als het verschil tussen de tijd waarin een proces klaar is om uitgevoerd te worden en de tijd waarin het proces CPU-tijd toegewezen krijgt.<\/p>\n<p>De steal-metric krijgt de virtuele machine van de hypervisor. De hypervisor specificeert echter niet welke andere processen hij uitvoert; hij zegt simpelweg: \"Terwijl ik bezig ben, kan ik je geen tijd geven.\" Bij KVM is de ondersteuning voor het tellen van steal toegevoegd in <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/449657\/\">de patches.<\/a><\/noindex>Er zijn twee belangrijke punten hier: <\/p>\n<ul>\n<li>De virtuele machine ervaart steal vanuit de hypervisor. Dit betekent dat, vanuit het perspectief van verlies, voor processen op de virtuele machine dit een indirecte meting is, die onderhevig kan zijn aan verschillende vervormingen.\n<\/li>\n<li>De hypervisor deelt niet met de virtuele machine welke andere taken hij uitvoert; het belangrijkste is dat hij geen tijd aan haar besteedt. Daardoor kan de virtuele machine zelf geen vervormingen in de steal-metric identificeren, die mogelijk konden worden beoordeeld op basis van de aard van concurrerende processen.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Wat be\u00efnvloedt steal<\/h2>\n<p><\/p>\n<h3>2.1. Berekening van steal<\/h3>\n<p>\nIn wezen wordt steal ongeveer op dezelfde manier berekend als de gewone CPU-utilisatie tijd. Er is niet veel informatie over hoe deze utilisatie wordt berekend. Misschien omdat de meeste mensen deze kwestie voor de hand liggend achten. Maar ook hier zijn er valkuilen. Voor een inzicht in dit proces kan men dit lezen. <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-05-09\/cpu-utilization-is-wrong.html\">het artikel van Brendann Gregg<\/a><\/noindex>: u leert over een aantal nuances bij het berekenen van de benutting en over situaties waarin deze berekening om de volgende redenen onjuist kan zijn:<\/p>\n<ul>\n<li>Oververhitting van de processor, waarbij cycli worden overgeslagen.\n<\/li>\n<li>In- en uitschakelen van turbo boost, waardoor de kloksnelheid van de processor verandert.\n<\/li>\n<li>Wijziging van de tijdsduur van een tijdsquantum, die optreedt bij gebruik van energiebesparende technologie\u00ebn van de processor, bijvoorbeeld SpeedStep.\n<\/li>\n<li>Probleem van het berekenen van het gemiddelde: een benutting van 80% gedurende \u00e9\u00e9n minuut kan een kortstondige piek van 100% verbergen.\n<\/li>\n<li>Cyclusblokkering (spin lock) leidt ertoe dat de processor benut wordt, maar het gebruikersproces geen vooruitgang merkt in zijn uitvoering. Als gevolg daarvan is de berekende benutting van de processor door het proces 100%, terwijl de processor tijd fysiek geen proces zal consumeren.\n<\/li>\n<\/ul>\n<p>\nIk heb geen artikelen gevonden die een vergelijkbare berekening voor steal beschrijven (als je iets weet \u2014 deel het in de reacties). Maar, volgens de bronnen, is het mechanisme van de berekening hetzelfde als voor benutting. Gewoon wordt er in de kernel nog een teller toegevoegd, specifiek voor het KVM-proces (virtuele machine), dat de duur meet van het wachten van het KVM-proces op processor tijd. De teller haalt informatie over de processor op uit zijn specificaties en kijkt of al zijn ticks worden benut door het virtuele proces. Als dat het geval is, beschouwen we de processor als alleen bezig met het virtuele machine proces. Anders informeren we dat de processor met iets anders bezig is, wat steal genereert. <\/p>\n<p>Het proces van het berekenen van steal wordt getroffen door dezelfde problemen als de reguliere benuttingsberekening. Het is niet zo dat deze problemen vaak voorkomen, maar ze zijn ontmoedigend.<\/p>\n<h3>2.2. Typen virtualisatie op KVM<\/h3>\n<p>\nOver het algemeen zijn er drie typen virtualisatie, en al deze worden door KVM ondersteund. Het type virtualisatie kan invloed hebben op het mechanisme van het ontstaan van steal.<\/p>\n<p><b>Translatie<\/b>. In dit geval verloopt de interactie van het besturingssysteem van de virtuele machine met de fysieke apparaten van de hypervisor ongeveer als volgt:<\/p>\n<ol>\n<li>Het gastbesturingssysteem geeft een opdracht aan zijn gastapparaat.\n<\/li>\n<li>De stuurprogramma van het gastapparaat ontvangt de opdracht, vormt een verzoek voor de BIOS van het apparaat en verstuurt deze naar de hypervisor.\n<\/li>\n<li>De hypervisor vertaalt opdrachten naar opdrachten voor het fysieke apparaat, waardoor het, onder andere, ook veiliger wordt.\n<\/li>\n<li>De stuurprogramma's van het fysieke apparaat ontvangen het gewijzigde commando en sturen het naar het fysieke apparaat zelf.\n<\/li>\n<li>De resultaten van de uitgevoerde opdrachten komen via dezelfde weg terug. \n<\/li>\n<\/ol>\n<p>\nHet voordeel van vertaling is dat het het mogelijk maakt om elk apparaat te emuleren en geen speciale aanpassingen aan de kernel van het besturingssysteem vereist. Maar hiervoor moet je in ruil daarvoor, voornamelijk, inboeten op snelheid. <\/p>\n<p><b>Hardwarevirtualisatie<\/b>. In dit geval begrijpt het apparaat op hardware-niveau de opdrachten vanuit het besturingssysteem. Dit is de snelste en beste manier. Maar helaas wordt het niet door alle fysieke apparaten, hypervisors en gastbesturingssystemen ondersteund. Momenteel zijn de belangrijkste apparaten die hardwarevirtualisatie ondersteunen, processors.<\/p>\n<p><b>Paravirtualisatie (paravirtualization)<\/b>. De meest gangbare optie voor apparaatvirtualisatie op KVM en in het algemeen de meest voorkomende modus van virtualisatie voor gastbesturingssystemen. Het kenmerk hiervan is dat de interactie met bepaalde subsystemen van de hypervisor (bijvoorbeeld met de netwerks of schijfstack) of het toewijzen van geheugenspagina's gebeurt met behulp van de API van de hypervisor, zonder dat laag-niveau opdrachten worden vertaald. Het nadeel van deze virtalisatiemethode is de noodzaak om de kernel van het gastbesturingssysteem te wijzigen, zodat deze met de hypervisor via deze API kan communiceren. Maar meestal wordt dit opgelost door speciale stuurprogramma's op het gastbesturingssysteem te installeren. In KVM wordt deze API <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/developerworks\/library\/l-virtio\/index.html\">virtio API<\/a><\/noindex>.<\/p>\n<p>Bij paravirtualisatie wordt, in vergelijking met vertaling, de weg naar het fysieke apparaat aanzienlijk verkort doordat opdrachten rechtstreeks van de virtuele machine naar het proces van de hypervisor op de host worden verzonden. Dit versnelt de uitvoering van alle instructies binnen de virtuele machine. In KVM is virtio API hiervoor verantwoordelijk, dat alleen werkt voor specifieke apparaten, zoals netwerk- of schijfadapters. Daarom worden binnen de virtuele machines virtio-stuurprogramma's ge\u00efnstalleerd. <\/p>\n<p>De keerzijde van zo'n versnelling is dat niet alle processen die binnen een virtuele machine worden uitgevoerd, daar blijven. Dit cre\u00ebert enkele speciale effecten die kunnen leiden tot verschijnselen op steal. Een gedetailleerd onderzoek van deze kwestie raad ik aan te beginnen met <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/239238\/\">Een API voor virtueel I\/O: virtio<\/a><\/noindex>.<\/p>\n<h3>2.3. \"Eerlijke\" scheduling<\/h3>\n<p>\nEen virtuele machine op een hypervisor is feitelijk een gewone proces dat zich houdt aan de wetten van scheduling (toewijzing van middelen tussen processen) in de Linux-kernel, laten we het daarom in detail bekijken. <\/p>\n<p>In Linux wordt de zogenaamde CFS, Completely Fair Scheduler, gebruikt, die vanaf kernel 2.6.23 de standaard scheduler is geworden. Om deze algoritme te begrijpen, kun je de Linux Kernel Architecture of de bronnen lezen. De essentie van CFS is het verdelen van processor tijd tussen processen op basis van de duur van hun uitvoering. Hoe meer processor tijd een proces vereist, hoe minder deze tijd het krijgt. Dit garandeert een \"eerlijk\" verloop van alle processen - zodat \u00e9\u00e9n proces niet voortdurend alle processors in beslag neemt, en andere processen ook uitgevoerd kunnen worden. <\/p>\n<p>Soms leidt zo'n paradigma tot interessante artefacten. Langdurige Linux-gebruikers herinneren zich vast nog de bevriezing van een gewone teksteditor op het bureaublad tijdens het starten van resource-intensievere applicaties zoals een compiler. Dit gebeurde omdat niet-resource-intensievere taken van bureaubladapplicaties concurreerden met taken die actief middelen verbruikten, zoals de compiler. CFS vindt dit oneerlijk, en daarom stopt het periodiek de teksteditor en laat het de processor de taken van de compiler verwerken. Dit is opgelost met behulp van het mechanisme <noindex><a rel=\"nofollow\" href=\"https:\/\/marc.info\/?l=linux-kernel&amp;m=128978361700898\">sched_autogroup<\/a><\/noindex>, maar er blijven veel andere kenmerken van de verdeling van processor tijd tussen taken bestaan. Eigenlijk is dit verhaal niet over hoe slecht alles is in CFS, maar een poging om de aandacht te vestigen op het feit dat een \"eerlijke\" verdeling van processor tijd geen triviale taak is.<\/p>\n<p>Een ander belangrijk punt in de scheduler is preemption. Dit is nodig om een te veeleisend proces van de CPU te verwijderen en andere processen de kans te geven om te draaien. Het proces van verwijderen wordt context switching genoemd, waarbij de context van de taak behouden blijft: de status van de stack, registers en meer, waarna het proces gaat wachten en een ander zijn plaats inneemt. Dit is een dure operatie voor het besturingssysteem en wordt zelden gebruikt, maar in wezen is er niets slechts aan. Frequent context switching kan duiden op een probleem in het besturingssysteem, maar doorgaans gaat het continu en wijst het op niets bijzonders.<\/p>\n<p>Dit lange verhaal is nodig om \u00e9\u00e9n feit uit te leggen: hoe meer CPU-bronnen een proces probeert te verbruiken in een eerlijke Linux-scheduler, hoe sneller het zal worden stopgezet, zodat andere processen ook de kans krijgen om te draaien. Of dit goed of slecht is, is een complexe vraag die afhankelijk is van verschillende belastingniveaus. Tot voor kort was de scheduler in Windows gericht op prioritaire verwerking van desktop-applicaties, waardoor achtergrondprocessen konden vastlopen. In Sun Solaris waren er vijf verschillende klassen van schedulers. Toen virtualisatie werd ge\u00efntroduceerd, werd een zesde toegevoegd. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opennet.ru\/man.shtml?topic=FSS&amp;category=7&amp;russian=4\">Fair share scheduler<\/a><\/noindex>, omdat de vorige vijf niet adequaat samenwerkten met de virtualisatie van Solaris Zones. Ik raad aan om deze materie gedetailleerd te bestuderen met boeken zoals <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Solaris-Internals-OpenSolaris-Kernel-Architecture\/dp\/0131482092\/\">Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture<\/a><\/noindex> of <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. Hoe monitor je steal?<\/h3>\n<p>\nSteal binnen een virtuele machine monitoren, net als elke andere CPU-metric, is eenvoudig: je kunt elk hulpmiddel voor het verzamelen van CPU-statistieken gebruiken. Het belangrijkste is dat de virtuele machine op Linux draait. Windows biedt deze informatie om de een of andere reden niet aan zijn gebruikers. \ud83d\ude41<\/p>\n<p><img decoding=\"async\" alt=\"Steal: wie steelt er CPU-tijd van virtuele machines\" src=\"\/wp-content\/uploads\/2019\/04\/3c7cd04f73fd6a74b86af81382090b69.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>De uitvoer van de top-opdracht: detailniveau van de CPU-belasting, in de uiterste rechterkolom \u2014 steal<\/i><\/p>\n<p>De moeilijkheid ontstaat bij het proberen deze informatie van de hypervisor te verkrijgen. Je kunt proberen steal op de hostmachine te voorspellen, bijvoorbeeld aan de hand van de parameter Load Average (LA) \u2014 het gemiddelde aantal processen dat in de wacht staat om uitgevoerd te worden. De berekeningsmethode voor deze parameter is complex, maar over het algemeen, als de LA genormaliseerd naar het aantal CPU-threads groter is dan 1, duidt dat erop dat de Linux-server met iets overbelast is. <\/p>\n<p>Wat verwachten al deze processen? Het voor de hand liggende antwoord is de processor. Maar het antwoord is niet helemaal juist, omdat de processor soms vrij is terwijl de LA hoog is. Denk terug aan, <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/911976\/redhat-nfs-cluster-high-load-average-suddenly\">hoe NFS eruit valt en hoe de LA daardoor toeneemt.<\/a><\/noindex>Dit kan ongeveer hetzelfde zijn met de schijf en andere in- en uitvoerapparaten. Maar in werkelijkheid kunnen processen wachten op het be\u00ebindigen van elke blokkade, zowel fysiek, gerelateerd aan de in- en uitvoerapparaten, als logisch, zoals bij mutexen. Ook blokkades op hardware-niveau (zoals de respons van de schijf) of op logica-niveau (de zogenaamde vergrendelingsprimitive, wat een heleboel entiteiten omvat, zoals adaptive mutexes, spinlocks, semaphores, condition variables, rw locks, ipc locks\u2026) vallen hieronder.<\/p>\n<p>Een andere eigenschap van LA is dat het als een gemiddeld waarde over het besturingssysteem wordt beschouwd. Bijvoorbeeld, 100 processen strijden om \u00e9\u00e9n bestand, waardoor LA=50. Zo'n hoge waarde lijkt erop te wijzen dat het besturingssysteem slecht functioneert. Maar voor bepaalde slecht geschreven code kan dit een normale staat zijn, waarbij het alleen voor die code slecht is, terwijl andere processen in het besturingssysteem daar geen hinder van ondervinden. <\/p>\n<p>Vanwege deze averaging (en dat over een periode van ten minste een minuut), is het bepalen van iets aan de hand van de LA-index geen dankbare taak, met zeer onduidelijke resultaten in specifieke gevallen. Als je probeert te begrijpen, zul je ontdekken dat in artikelen op Wikipedia en andere beschikbare resources alleen de eenvoudigste gevallen worden beschreven, zonder diepgaande uitleg van het proces. Ik verwijs alle ge\u00efnteresseerden opnieuw, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-08-08\/linux-load-averages.html\">hiernaartoe, naar Brendann Gregg<\/a><\/noindex> \u00a0\u2014 verder via de links. Voor wie geen zin heeft om het in het Engels te lezen \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/335326\/\">de vertaling van zijn populaire artikel over LA<\/a><\/noindex>.<\/p>\n<h2>3. Speciale effecten<\/h2>\n<p>\nLaten we nu stilstaan bij de belangrijkste gevallen waarin steal voorkomt, waarmee we te maken hebben gehad. Ik zal uitleggen hoe ze voortkomen uit alles wat hierboven is gezegd en hoe ze zich verhouden tot de indicatoren op de hypervisor.<\/p>\n<p><b>Hernieuwing<\/b>. Het eenvoudigste en meest voorkomende: de hypervisor is overbezet. Inderdaad, er zijn veel draaiende virtuele machines, een hoog CPU-verbruik binnen deze machines, grote concurrentie, de LA-utilisatie is hoger dan 1 (genormaliseerd op de CPU-threads). Binnen al deze virtuele machines verloopt alles traag. De steal die van de hypervisor komt, neemt ook toe, het is nodig om de belasting opnieuw te verdelen of iemand uit te schakelen. Kortom, alles is logisch en begrijpelijk.<\/p>\n<p><b>Paravirtualisatie versus zelfstandige instanties<\/b>. Op de hypervisor is er \u00e9\u00e9n enkele virtuele machine, die een klein deel ervan gebruikt, maar een grote belasting met zich meebrengt op het gebied van input\/output, bijvoorbeeld bij de schijf. En ergens in deze machine verschijnt een kleine steal, tot 10% (zoals meerdere uitgevoerde experimenten laten zien).<\/p>\n<p>Een interessante situatie. Steal verschijnt hier juist door vergrendelingen op het niveau van para-virtualisatie drivers. Binnen de virtuele machine wordt er een onderbreking aangemaakt, die door de driver wordt verwerkt en naar de hypervisor gaat. Door de verwerking van de onderbreking lijkt het voor de virtuele machine alsof er een verzoek is verstuurd, ze is klaar om uitgevoerd te worden en wacht op de CPU, maar krijgt geen processortijd. De virtuele machine denkt dat deze tijd is gestolen. <\/p>\n<p>Dit gebeurt op het moment dat de buffer wordt verzonden, het gaat naar de kernelruimte van de hypervisor en we beginnen te wachten. Hoewel het voor de virtuele machine lijkt alsof het onmiddellijk terug zou moeten komen. Volgens het algoritme voor het berekenen van steal wordt deze tijd als gestolen beschouwd. Waarschijnlijk zijn er in deze situatie nog andere mechanismen (zoals de verwerking van nog andere sys calls), maar die zouden niet veel anders moeten zijn.<\/p>\n<p><b>Scheduler tegen hoogbelaste virtuele machines<\/b>. Wanneer \u00e9\u00e9n virtuele machine meer last heeft van steal dan anderen, heeft dit te maken met de scheduler. Hoe meer de proces de CPU belast, hoe sneller de scheduler het eruit gooit zodat anderen ook kunnen werken. Als een virtuele machine slechts een beetje verbruikt, zal ze bijna geen steal merken: haar proces zat eerlijk te wachten, wat betekent dat ze meer tijd moet krijgen. Als de virtuele machine maximale belasting op al haar kernen genereert, wordt ze vaker van de CPU gegooid en probeert men haar niet veel tijd te geven. <\/p>\n<p>Het is nog erger wanneer processen binnen de virtuele machine proberen meer CPU te krijgen omdat ze de gegevensverwerking niet aankunnen. In dat geval zal het besturingssysteem op de hypervisor, door eerlijke optimalisatie, steeds minder processortijd toekennen. Dit proces gaat lawineachtig, en steal schiet omhoog, hoewel de andere virtuele machines het nauwelijks kunnen merken. Hoe meer kernen, hoe slechter het gaat voor de machine die onder druk staat. Kortom, hoogbelaste virtuele machines met veel kernen lijden het meest.<\/p>\n<p><b>Lage LA, maar er is steal<\/b>. Als de LA ongeveer 0,7 is (dat wil zeggen, de hypervisor lijkt niet overbelast), maar er binnen afzonderlijke virtuele machines steal wordt waargenomen:<\/p>\n<ul>\n<li>De al eerder beschreven variant met paravirtualisatie. De virtuele machine kan statistieken ontvangen die wijzen op steal, ook al is alles in orde met de hypervisor. Uit onze experimenten blijkt dat deze steal niet meer dan 10% bedraagt en geen significante invloed zou moeten hebben op de prestaties van applicaties binnen de virtuele machine.\n<\/li>\n<li>De parameter LA wordt onterecht beschouwd. In feite is deze op elk specifiek moment juist, maar gemiddeld over een minuut wordt hij lager weergegeven. Bijvoorbeeld, als een virtuele machine een derde van de hypervisor zijn CPU's precies een halve minuut gebruikt, zal de LA voor de hypervisor in die minuut 0,15 zijn; vier van dergelijke virtuele machines die gelijktijdig werken, zullen 0,6 geven. En het feit dat er een wilde steal van 25% was op elke van hen gedurende een halve minuut kan niet meer worden hersteld.\n<\/li>\n<li>Weer, door de scheduler die beslist dat iemand te veel verbruikt, en laat diegene maar wachten. Ondertussen wissel ik contexten, verwerk interrupts en houd me bezig met andere belangrijke systeemtaken. Uiteindelijk ervaren sommige virtuele machines geen problemen, terwijl andere ernstige prestatieafbraak ondervinden.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>4. Andere vervormingen<\/h2>\n<p>\nEr zijn nog miljoenen redenen voor vervormingen in de eerlijke toewijzing van CPU-tijd op een virtuele machine. Bijvoorbeeld, hyperthreading en NUMA compliceren de berekeningen, omdat de scheduler gewichten gebruikt die het nog moeilijker maken om de core voor de uitvoering van een proces te kiezen bij contextwisselingen.<\/p>\n<p>Soms zijn er vervormingen door technologie\u00ebn zoals turboboost of, omgekeerd, energiebesparingsmodi, die bij het berekenen van de benutting de frequentie of zelfs de tijdsquantum op de server kunstmatig kunnen verhogen of verlagen. Het inschakelen van turboboost vermindert de prestaties van \u00e9\u00e9n CPU-thread ten gevolge van het verhogen van de prestaties van een andere. Op dat moment worden de actuele frequentiegegevens niet naar de virtuele machine verzonden, waardoor deze denkt dat haar tijd wordt gestolen (bijvoorbeeld, het vroeg om 2 GHz, maar kreeg de helft). <\/p>\n<p>Kortom, er kunnen veel redenen zijn voor vervormingen. In een specifiek systeem kunt u nog meer ontdekken. Begin het beste met de boeken waar ik eerder naar heb gelinkt en het verzamelen van statistieken van de hypervisor met tools zoals perf, sysdig, systemtap, die er <noindex><a rel=\"nofollow\" href=\"https:\/\/jvns.ca\/blog\/2017\/07\/05\/linux-tracing-systems\/\">tientallen zijn.<\/a><\/noindex>.<\/p>\n<h2>5. Conclusies<\/h2>\n<p><\/p>\n<ol>\n<li>Een bepaalde hoeveelheid steal kan optreden door para-virtualisatie en kan als normaal worden beschouwd. Op het internet wordt geschreven dat deze waarde 5-10% kan zijn. Dit hangt af van de applicaties binnen de virtuele machine en van de belasting die deze op zijn fysieke apparaten legt. Het is belangrijk om in de gaten te houden hoe de applicaties zich gedragen binnen de virtuele machines.\n<\/li>\n<li>De verhouding tussen de belasting op de hypervisor en steal binnen de virtuele machine is niet altijd eenduidig met elkaar verbonden; beide beoordelingen van steal kunnen foutief zijn in specifieke situaties bij verschillende belastingen.\n<\/li>\n<li>De scheduler is niet vriendelijk voor processen die veel vragen. Hij probeert minder te geven aan degenen die meer vragen. Grote virtuele machines zijn een kwaad.\n<\/li>\n<li>Een kleine hoeveelheid steal kan normaal zijn, zelfs zonder para-virtualisatie (rekening houdend met de belasting binnen de virtuele machine, de eigenschappen van de belasting van buren, de verdeling van de belasting over threads en andere factoren).\n<\/li>\n<li>Als je de steal in een specifiek systeem wilt achterhalen, moet je verschillende opties onderzoeken, metrics verzamelen, deze zorgvuldig analyseren en nadenken over hoe je de belasting gelijkmatig kunt verdelen. Er kunnen afwijkingen zijn bij alle gevallen die experimenteel moeten worden bevestigd of bekeken in de kernel debugger.\n<\/li>\n<\/ol>\n<p>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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: wie steelt CPU-tijd van virtuele machines | ProHoster","description":"Hallo!","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/32331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=32331"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/32331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/24147"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=32331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=32331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=32331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}