{"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\/da\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","title":{"rendered":"Steal: hvem stj\u00e6ler CPU-tid fra virtualiseringer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Steal: hvem stj\u00e6ler CPU-tid fra virtualiseringer\" src=\"\/wp-content\/uploads\/2019\/04\/23cac5d3cc3295dc6f1014e9fda36b89.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHej! Jeg vil gerne forklare p\u00e5 en enkel m\u00e5de, hvordan steal opst\u00e5r inden for virtuelle maskiner, samt nogle uventede artefakter, vi er st\u00f8dt p\u00e5 under vores unders\u00f8gelse, som jeg har dykket ned i som teknisk direkt\u00f8r for cloud-platformen. <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Mail.ru Cloud Solutions<\/a><\/noindex>. Platformen k\u00f8rer p\u00e5 KVM.<\/p>\n<p>CPU steal time \u2014 er den tid, hvor den virtuelle maskine ikke modtager CPU-ressourcer til sin udf\u00f8relse. Denne tid t\u00e6lles kun i g\u00e6steoperativsystemer i virtualiseringsmilj\u00f8er. \u00c5rsagerne til, hvor disse tildelte ressourcer g\u00e5r hen, er desv\u00e6rre temmelig uklare. Vi besluttede os for at unders\u00f8ge dette n\u00e6rmere og gennemf\u00f8rte en r\u00e6kke eksperimenter. Selvom vi ikke ved alt om steal nu, har vi nogle interessante indsigter at dele.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>1. Hvad er steal<\/h2>\n<p>\nS\u00e5, steal \u2014 er en metrisk m\u00e5ling, der indikerer mangel p\u00e5 CPU-tid til processerne inden for den virtuelle maskine. Som beskrevet <noindex><a rel=\"nofollow\" href=\"https:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/stable\/linux.git\/patch\/?id=c9aaa8957f203bd6df83b002fb40b98390bed078\">i KVM-kernelpatchen<\/a><\/noindex>, er steal den tid, hvor hypervisoren k\u00f8rer andre processer p\u00e5 v\u00e6rtsoperativsystemet, selvom den har placeret den virtuelle maskines proces i k\u00f8 til udf\u00f8relse. Det vil sige, steal beregnes som forskellen mellem den tid, hvor processen er klar til at blive udf\u00f8rt, og den tid, hvor processen f\u00e5r tildelt CPU-tid.<\/p>\n<p>Den virtuelle maskine modtager steal-metrikken fra hypervisoren. Hypervisoren specificerer ikke, hvilke andre processer den udf\u00f8rer, men siger blot \"jeg er optaget, s\u00e5 jeg kan ikke give dig tid lige nu\". I KVM er st\u00f8tten til beregning af steal tilf\u00f8jet i <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/449657\/\">patchene.<\/a><\/noindex>Der er to hovedpunkter her: <\/p>\n<ul>\n<li>Den virtuelle maskine bliver informeret om steal af hypervisoren. Det vil sige, at set fra tabernes perspektiv, er det for processerne p\u00e5 selve virtualiseringerne en indirekte m\u00e5ling, som kan v\u00e6re udsat for forskellige forvr\u00e6ngninger.\n<\/li>\n<li>Hypervisoren deler ikke med virtualiseringen, hvad den er optaget med \u2014 det vigtigste er, at den ikke giver tid til den. Af denne grund kan selve virtualiseringen ikke identificere forvr\u00e6ngninger i steal-metrikken, som kunne vurderes ud fra karakteren af de konkurrerende processer.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Hvad p\u00e5virker steal<\/h2>\n<p><\/p>\n<h3>2.1. Beregning af steal<\/h3>\n<p>\nI bundet betragtes steal stort set ligesom den normale CPU-udnyttelse. Der er ikke meget information om, hvordan udnyttelsen beregnes. M\u00e5ske fordi de fleste anser dette sp\u00f8rgsm\u00e5l for at v\u00e6re \u00e5benlyst. Men der kan ogs\u00e5 v\u00e6re faldgruber her. For at blive bekendt med denne proces kan du l\u00e6se <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-05-09\/cpu-utilization-is-wrong.html\">artiklen af Brendann Gregg<\/a><\/noindex>: du vil l\u00e6re om en r\u00e6kke nuanceforskelle ved beregningen af udnyttelse og om situationer, hvor denne beregning vil v\u00e6re fejlagtig af f\u00f8lgende grunde:<\/p>\n<ul>\n<li>Overophedning af CPU'en, hvor der springes cykler over.\n<\/li>\n<li>T\u00e6nd\/sluk for turbo boost, hvilket \u00e6ndrer CPU'ens klokfrekvens.\n<\/li>\n<li>\u00c6ndring af tidskvantitet, der sker ved brug af CPU-energibesparende teknologier, som f.eks. SpeedStep.\n<\/li>\n<li>Problemet med at beregne gennemsnittet: en vurdering af udnyttelsen p\u00e5 80 % over et minut kan skjule et kortvarigt burst p\u00e5 100 %.\n<\/li>\n<li>Cyclic lock (spin lock) resulterer i, at CPU'en er udnyttet, men brugerprocessen ser ikke fremgang i sin udf\u00f8relse. Som resultat vil den beregnede udnyttelse af CPU'en for processen v\u00e6re 100 %, selvom CPU-tid ikke fysisk bliver forbrugt.\n<\/li>\n<\/ul>\n<p>\nJeg fandt ikke artikler, der beskriver en lignende beregning for steal (hvis du ved det \u2014 del venligst i kommentarerne). Men if\u00f8lge kildekoden er beregningsmekanismen den samme som for udnyttelse. Bare i kernen tilf\u00f8jes der endnu en t\u00e6ller, specifikt for KVM-processen (virtuelle maskine-proces), der registrerer varigheden af KVM-processens ventetid p\u00e5 CPU-tid. T\u00e6lleren henter oplysninger om CPU'en fra dens specifikation og unders\u00f8ger, om alle dens tikker er udnyttet af virtualmaskineprocessen. Hvis de er, s\u00e5 antager vi, at CPU'en kun har v\u00e6ret involveret i den virtuelle maskine. I mods\u00e6tning hertil informerer vi om, at CPU'en har v\u00e6ret involveret i noget andet og at steal er opst\u00e5et. <\/p>\n<p>Processen til at beregne steal er udsat for de samme problemer som almindelig udnyttelsesevaluering. Man kan ikke sige, at s\u00e5danne problemer opst\u00e5r ofte, men de virker nedsl\u00e5ende.<\/p>\n<h3>2.2. Typer af virtualisering p\u00e5 KVM<\/h3>\n<p>\nGenerelt er der tre typer virtualisering, og alle underst\u00f8ttes af KVM. Den type virtualisering, der anvendes, kan p\u00e5virke mekanismen for opst\u00e5en af steal.<\/p>\n<p><b>Overs\u00e6ttelse<\/b>I dette tilf\u00e6lde arbejder operativsystemet for den virtuelle maskine med hypervisorens fysiske enheder omtrent s\u00e5dan her:<\/p>\n<ol>\n<li>G\u00e6steoperativsystemet sender en kommando til sin g\u00e6steenhed.\n<\/li>\n<li>Driveren for g\u00e6steenheden modtager kommandoen, danner en foresp\u00f8rgsel til enhedens BIOS og sender den til hypervisoren.\n<\/li>\n<li>Hypervisorens proces overs\u00e6tter kommandoen til en kommando for den fysiske enhed og g\u00f8r den blandt andet mere sikker.\n<\/li>\n<li>Driveren for den fysiske enhed modtager den modificerede kommando og sender den videre til den fysiske enhed.\n<\/li>\n<li>Resultaterne af kommandoens udf\u00f8relse g\u00e5r tilbage ad den samme vej. \n<\/li>\n<\/ol>\n<p>\nFordelen ved overs\u00e6ttelsen er, at den muligg\u00f8r emulering af enhver enhed og ikke kr\u00e6ver s\u00e6rlig forberedelse af operativsystemets kerne. Men prisen betales f\u00f8rst og fremmest i form af hastighed. <\/p>\n<p><b>Hardwarevirtualisering<\/b>I dette tilf\u00e6lde forst\u00e5r enheden p\u00e5 hardware-niveau kommandoer fra operativsystemet. Dette er den hurtigste og bedste metode. Men desv\u00e6rre underst\u00f8ttes den ikke af alle fysiske enheder, hypervisorer og g\u00e6steoperativsystemer. P\u00e5 nuv\u00e6rende tidspunkt er de prim\u00e6re enheder, der underst\u00f8tter hardwarevirtualisering, processorer.<\/p>\n<p><b>Paravirtualisering (paravirtualization)<\/b>Dette er den mest udbredte form for enhedsvirtualisering p\u00e5 KVM og generelt den mest udbredte tilstand for g\u00e6steoperativsystemer. Dets s\u00e6rligt ved er, at arbejdet med nogle af hypervisorens underliggende systemer (som netv\u00e6rks- eller diskstakken) eller tildeling af hukommelsessider sker ved hj\u00e6lp af hypervisorens API, uden overs\u00e6ttelse af lavniveau kommandoer. Ulempen ved denne virtualiseringsmetode er behovet for at modificere g\u00e6steoperativsystemets kerne, s\u00e5 den kan interagere med hypervisoren via dette API. Men dette l\u00f8ses normalt ved at installere s\u00e6rlige drivere p\u00e5 g\u00e6steoperativsystemet. I KVM kaldes dette API <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/developerworks\/library\/l-virtio\/index.html\">virtio API<\/a><\/noindex>.<\/p>\n<p>Ved paravirtualisering, i forhold til translation, forkortes vejen til det fysiske apparat betydeligt ved at sende kommandoer direkte fra den virtuelle maskine til hypervisorens proces p\u00e5 v\u00e6rten. Dette muligg\u00f8r en hurtigere udf\u00f8relse af alle instruktioner inde i den virtuelle maskine. I KVM h\u00e5ndteres dette af virtio API, som kun fungerer for visse enheder, s\u00e5som netv\u00e6rks- eller diskadaptere. Derfor installeres virtio-drivere inde i de virtuelle maskiner. <\/p>\n<p>Den bagside af denne acceleration er, at ikke alle processer, der udf\u00f8res inde i virtuellen, forbliver inde i den. Dette skaber nogle specielle effekter, der kan f\u00f8re til problemer med steal. Et grundigt studie af dette emne anbefales at starte med <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/239238\/\">En API til virtuel I\/O: virtio<\/a><\/noindex>.<\/p>\n<h3>2.3. \"Retf\u00e6rdig\" planl\u00e6gning<\/h3>\n<p>\nDen virtuelle maskine p\u00e5 hypervisoren er i realiteten en almindelig proces, som underkastes reglerne for planl\u00e6gning (ressourcefordeling mellem processer) i Linux-kernen, s\u00e5 vi ser n\u00e6rmere p\u00e5 det. <\/p>\n<p>I Linux anvendes den s\u00e5kaldte CFS, Completely Fair Scheduler, som fra kernel 2.6.23 blev standardplanl\u00e6ggeren. For at forst\u00e5 denne algoritme kan man l\u00e6se Linux Kernel Architecture eller kildekoden. Essensen af CFS ligger i fordelingen af CPU-tid mellem processer afh\u00e6ngigt af varigheden af deres udf\u00f8relse. Jo mere CPU-tid en proces kr\u00e6ver, desto mindre tid f\u00e5r den. Dette sikrer en \"retf\u00e6rdig\" udf\u00f8relse af alle processer \u2014 s\u00e5 \u00e9n proces ikke konstant optager alle CPU'er, og de andre processer ogs\u00e5 kan k\u00f8re. <\/p>\n<p>Nogle gange f\u00f8rer denne paradigme til interessante artefakter. Langvarige brugere af Linux husker sikkert, at den almindelige teksteditor p\u00e5 skrivebordet fryser under opstarten af ressourcekr\u00e6vende applikationer som kompilatorer. Dette skete, fordi ikke-ressourcekr\u00e6vende opgaver fra skrivebordsapplikationer konkurrerede med opgaver, der aktivt kr\u00e6vede ressourcer, som kompilatoren. CFS anser, at dette er uretf\u00e6rdigt, s\u00e5 den stopper periodisk teksteditoren og giver CPU'en tid til at behandle kompilatorens opgaver. Dette blev rettet ved hj\u00e6lp af mekanismen <noindex><a rel=\"nofollow\" href=\"https:\/\/marc.info\/?l=linux-kernel&amp;m=128978361700898\">sched_autogroup<\/a><\/noindex>, men der er stadig mange andre funktioner ved fordeling af processorens tid mellem opgaver. Egentlig handler denne fort\u00e6lling ikke om, hvor d\u00e5rligt det er i CFS, men om at p\u00e5pege, at en \"fair\" fordeling af processorens tid ikke er en triviel opgave.<\/p>\n<p>En anden vigtig faktor i scheduler er preemption. Dette er n\u00f8dvendigt for at tvinge en overbelastet proces v\u00e6k fra processoren og give andre mulighed for at arbejde. Procesudvisningen kaldes context switching, som er skiftet af processorens kontekst. Her gemmes hele opgavekonteksten: stackens tilstand, registre og andet, hvorefter processen venter, mens en anden tr\u00e6der ind. Dette er en dyr operation for OS, og den bruges sj\u00e6ldent, men der er i bund og grund ikke noget d\u00e5rligt i den. Hyppig kontekstskift kan indikere et problem i OS, men normalt g\u00e5r det kontinuerligt og angiver ikke noget s\u00e6rligt.<\/p>\n<p>Denne lange fort\u00e6lling er n\u00f8dvendig for at forklare en kendsgerning: jo flere ressourcer processorens opgave fors\u00f8ger at forbruge i den \u00e6rlige scheduler i Linux, jo hurtigere vil den blive stoppet, s\u00e5 andre processer ogs\u00e5 kan arbejde. Om dette er korrekt eller ej er et komplekst sp\u00f8rgsm\u00e5l, der varierer afh\u00e6ngigt af belastningen. I Windows var scheduler indtil for nylig fokuseret p\u00e5 prioriteret behandling af desktop-applikationer, hvilket kunne for\u00e5rsage, at baggrundsprocesser hang. I Sun Solaris var der fem forskellige klasser af schedulere. Da virtualisering blev lanceret, blev der tilf\u00f8jet en sjette. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opennet.ru\/man.shtml?topic=FSS&amp;category=7&amp;russian=4\">Fair share scheduler<\/a><\/noindex>, fordi de tidligere fem arbejdede utilstr\u00e6kkeligt med Solaris Zones virtualisering. Jeg anbefaler at starte en detaljeret unders\u00f8gelse af dette emne med b\u00f8ger som <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Solaris-Internals-OpenSolaris-Kernel-Architecture\/dp\/0131482092\/\">Solaris Internals: Solaris 10 og OpenSolaris Kernel Architecture<\/a><\/noindex> eller <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. Hvordan overv\u00e5ge steal?<\/h3>\n<p>\nAt overv\u00e5ge steal inde i en virtuel maskine, ligesom enhver anden processor-metrik, er enkelt: man kan bruge ethvert v\u00e6rkt\u00f8j til at m\u00e5le processor-metrikker. Det vigtigste er, at virtualmaskinen k\u00f8rer p\u00e5 Linux. Windows giver \u00e5benbart ikke s\u00e5dan information til sine brugere. \ud83d\ude41<\/p>\n<p><img decoding=\"async\" alt=\"Steal: hvem stj\u00e6ler CPU-tid fra virtualiseringer\" src=\"\/wp-content\/uploads\/2019\/04\/3c7cd04f73fd6a74b86af81382090b69.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Output fra kommandoen top: detaljering af belastningen p\u00e5 processoren, helt til h\u00f8jre kolonne - steal<\/i><\/p>\n<p>Det opst\u00e5r vanskeligheder, n\u00e5r man fors\u00f8ger at hente disse oplysninger fra hypervisoren. Man kan m\u00e5ske forudsige steal p\u00e5 v\u00e6rtmaskinen, for eksempel ved at se p\u00e5 Load Average (LA) \u2014 det gennemsnitlige antal processer, der venter i k\u00f8 p\u00e5 at blive udf\u00f8rt. Metoden til at beregne denne parameter er kompliceret, men generelt, hvis den normaliserede LA pr. antal CPU-tr\u00e5de er over 1, indikerer det, at serveren med Linux er belastet. <\/p>\n<p>Hvad venter alle disse processer p\u00e5? Det \u00e5benlyse svar er CPU'en. Men svaret er ikke helt korrekt, fordi CPU'en nogle gange er ledig, mens LA skyder i vejret. Husk, <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/911976\/redhat-nfs-cluster-high-load-average-suddenly\">hvordan NFS falder ud, og hvordan LA stiger<\/a><\/noindex>Cirka p\u00e5 samme m\u00e5de kan det v\u00e6re med disken og andre input\/output enheder. Men i virkeligheden kan processer vente p\u00e5 at enhver l\u00e5s, b\u00e5de fysisk, relateret til input\/output enheden, og logisk, for eksempel en mutex, er afsluttet. Herunder falder l\u00e5se p\u00e5 hardware-niveau (som svaret fra disken) eller logikniveau (de s\u00e5kaldte l\u00e5seprimitiver, som omfatter mange enheder, mutex adaptive og spin, semaforer, betingede variabler, rw locks, ipc locks\u2026).<\/p>\n<p>En anden egenskab ved LA er, at det beregnes som et gennemsnit for operativsystemet. For eksempel, hvis 100 processer konkurrerer om en fil, er LA=50. Et s\u00e5 h\u00f8jt tal tyder umiddelbart p\u00e5, at operativsystemet har det skidt. Men for noget d\u00e5rligt skrevet kode kan dette v\u00e6re en normal tilstand, mens kun den specifikke proces er p\u00e5virket, mens andre processer i operativsystemet ikke lider. <\/p>\n<p>P\u00e5 grund af denne gennemsnitsberegning (som str\u00e6kker sig over mindst et minut) er det at fors\u00f8ge at bestemme noget ud fra LA-v\u00e6rdien ikke en lunefuld opgave, med ret usikre resultater i konkrete tilf\u00e6lde. Hvis du pr\u00f8ver at finde ud af det, vil du opdage, at artiklerne p\u00e5 Wikipedia og andre tilg\u00e6ngelige ressourcer kun beskriver de mest grundl\u00e6ggende tilf\u00e6lde uden dybdeg\u00e5ende forklaring af processen. Til alle interesserede sender jeg igen, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-08-08\/linux-load-averages.html\">herhen til Brendann Gregg<\/a><\/noindex> \u00a0\u2014 videre via links. For dem, der ikke orker engelsk \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/335326\/\">overs\u00e6ttelsen af hans popul\u00e6re artikel om LA<\/a><\/noindex>.<\/p>\n<h2>3. Specialeffekter<\/h2>\n<p>\nLad os nu fokusere p\u00e5 de vigtigste tilf\u00e6lde af steal, som vi har st\u00f8dt p\u00e5. Jeg vil forklare, hvordan de fremg\u00e5r af det ovenst\u00e5ende og hvordan de forholder sig til indikationerne p\u00e5 hypervisoren.<\/p>\n<p><b>Overudnyttelse<\/b>. Det mest almindelige og hyppigste: hypervisoren er blevet genbrugt. Faktisk k\u00f8rer der mange virtuelle maskiner, med stort CPU-forbrug inden i dem, stor konkurrence, og udnyttelsen er over 1 (i normalisering efter CPU-tr\u00e5de). Inden i alle VM'er er der alt for meget lag. Steal, der overf\u00f8res fra hypervisoren, vokser ogs\u00e5, og der skal redistribueres belastning eller slukkes for nogle. Generelt er det alt sammen logisk og forst\u00e5eligt.<\/p>\n<p><b>Paravirtualisering mod ensomme instanser<\/b>. P\u00e5 hypervisoren k\u00f8rer der kun \u00e9n enkelt virtuel maskine, som forbruger en lille del af den, men den giver en stor belastning p\u00e5 input\/output, for eksempel vedr\u00f8rende disk. Og der dukker et lille steal op i den, op til 10 % (som flere gennemf\u00f8rte eksperimenter viser).<\/p>\n<p>En interessant case. Steal optr\u00e6der her netop p\u00e5 grund af de blokeringer, der er p\u00e5 niveauet af paravirtualiserede drivere. Inden i VM'en oprettes en afbrydelse, behandles af driveren og g\u00e5r til hypervisoren. P\u00e5 grund af behandlingen af afbrydelsen p\u00e5 hypervisoren ser VM'en det som en sendt anmodning, den er klar til udf\u00f8relse og venter p\u00e5 processoren, men f\u00e5r ikke processtid. VM'en tror, at denne tid er stj\u00e5let. <\/p>\n<p>Dette sker i det \u00f8jeblik, hvor bufferen sendes, den g\u00e5r ind i kernel space af hypervisoren, og vi begynder at vente p\u00e5 det. Selvom, set fra VM'ens synspunkt, burde det straks vende tilbage. F\u00f8lgelig betragtes denne tid som stj\u00e5let if\u00f8lge algoritmen for beregning af steal. Sandsynligvis kan der v\u00e6re andre mekanismer i denne situation (for eksempel behandling af andre sys calls), men de b\u00f8r ikke adskille sig meget.<\/p>\n<p><b>Scheduler mod h\u00f8jtydende VM'er<\/b>. N\u00e5r en VM lider mere af steal end de andre, h\u00e6nger det netop sammen med scheduler'en. Jo mere en proces belaster processoren, jo hurtigere vil scheduler'en skubbe den ud, s\u00e5 de andre ogs\u00e5 kan f\u00e5 tid til at arbejde. Hvis VM'en forbruger lidt, ser den n\u00e6sten ikke steal: dens proces har v\u00e6ret stille og ventet, den skal have mere tid. Hvis VM'en genererer maksimal belastning p\u00e5 alle sine kerner, bliver den oftere skubbet ud af processoren og f\u00e5r ikke meget tid. <\/p>\n<p>Endnu v\u00e6rre er det, n\u00e5r processer inden i en virtuel maskine pr\u00f8ver at f\u00e5 mere processorkraft, fordi de ikke kan h\u00e5ndtere databehandlingen. S\u00e5 vil operativsystemet p\u00e5 hypervisoren, ved hj\u00e6lp af \u00e6rlig optimering, give mindre og mindre processortid. Denne proces sker lavineagtigt, og steal-parameteren stiger til himmels, selvom de andre virtuelle maskiner knap bem\u00e6rker det. Jo flere kerner, jo v\u00e6rre for den maskine, der rammes. Kort sagt, de mest belastede virtuelle maskiner med mange kerner lider mest.<\/p>\n<p><b>Lav LA, men der er steal<\/b>. Hvis LA er cirka 0,7 (dvs. hypervisoren virker underbelastet), men der observeres steal i enkelte virtuelle maskiner:<\/p>\n<ul>\n<li>Den tidligere beskrevne situation med para-virtualisering. Den virtuelle maskine kan modtage metrikker, der indikerer steal, selvom alt ser fint ud p\u00e5 hypervisoren. If\u00f8lge vores eksperimenter overstiger s\u00e5dan steal ikke 10 % og b\u00f8r ikke have v\u00e6sentlig indflydelse p\u00e5 ydeevnen for applikationerne inden i den virtuelle maskine.\n<\/li>\n<li>Parameteren LA betragtes forkert. Mere pr\u00e6cist, den betragtes korrekt p\u00e5 ethvert givet tidspunkt, men n\u00e5r den gennemsnitlige for en minut beregnes, bliver den undervurderet. For eksempel, hvis en virtuel maskine i en tredjedel af hypervisoren bruger alle sine processorer i pr\u00e6cis et halvt minut, vil LA for hypervisoren i l\u00f8bet af et minut v\u00e6re 0,15; fire s\u00e5danne virtuelle maskiner, der arbejder samtidig, giver 0,6. Og det faktum, at der var et voldsomt steal p\u00e5 hver af dem p\u00e5 25 % i et halvt minut, vil ikke kunne hentes.\n<\/li>\n<li>Igen p\u00e5 grund af schedulerens beslutning om, at nogen spiser for meget, og at denne person skal vente. Imens vil jeg skifte kontekst, behandle interrupts og tage mig af andre vigtige systemopgaver. Som resultat ser nogle virtuelle maskiner ingen problemer, mens andre oplever alvorlig nedgang i ydeevnen.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>4. Andre forvr\u00e6ngninger<\/h2>\n<p>\nDer er ogs\u00e5 en million andre \u00e5rsager til forvr\u00e6ngninger i den \u00e6rlige givelse af processortid p\u00e5 en virtuel maskine. For eksempel skaber hyper-threading og NUMA komplikationer i beregningerne. De forvirrer valget af kerne til udf\u00f8relse af processen, fordi scheduleren bruger koefficienter - v\u00e6gte, der g\u00f8r beregningen endnu vanskeligere ved kontekstskift.<\/p>\n<p>Der er forvr\u00e6ngninger p\u00e5 grund af teknologier som turbo boost eller omvendt, energibesparende tilstande, som ved beregningen af udnyttelse kunstigt kan h\u00e6ve eller s\u00e6nke frekvensen eller endda tidskvanten p\u00e5 serveren. Aktivering af turbo boost reducerer ydelsen af en CPU-tr\u00e5d p\u00e5 grund af \u00f8get ydelse fra en anden. P\u00e5 dette tidspunkt transmitteres oplysninger om den aktuelle processorfremsening ikke til den virtuelle maskine, og den tror, at dens tid bliver stj\u00e5let (for eksempel, hvis den bad om 2 GHz, men fik halvdelen). <\/p>\n<p>Generelt kan der v\u00e6re mange \u00e5rsager til forvr\u00e6ngninger. I et specifikt system kan du opdage noget andet. Det er bedst at starte med de b\u00f8ger, som jeg har givet links til ovenfor, og at tage statistikker fra hypervisoren ved hj\u00e6lp af v\u00e6rkt\u00f8jer som perf, sysdig, systemtap, af hvilke der er <noindex><a rel=\"nofollow\" href=\"https:\/\/jvns.ca\/blog\/2017\/07\/05\/linux-tracing-systems\/\">snesevis<\/a><\/noindex>.<\/p>\n<h2>5. Konklusioner<\/h2>\n<p><\/p>\n<ol>\n<li>En vis m\u00e6ngde steal kan opst\u00e5 p\u00e5 grund af paravirtualisering, og det kan betragtes som normalt. P\u00e5 internettet siger de, at denne v\u00e6rdi kan v\u00e6re mellem 5-10 %. Det afh\u00e6nger af de applikationer, der k\u00f8rer i den virtuelle maskine, og hvilken belastning de giver til deres fysiske enheder. Her er det vigtigt at v\u00e6re opm\u00e6rksom p\u00e5, hvordan applikationerne klarer sig inden i de virtuelle maskiner.\n<\/li>\n<li>Forholdet mellem belastningen p\u00e5 hypervisoren og steal inde i den virtuelle maskine er ikke altid entydigt sammenh\u00e6ngende, og begge vurderinger af steal kan v\u00e6re forkerte i specifikke situationer under forskellige belastninger.\n<\/li>\n<li>Planl\u00e6ggeren er ikke venlig overfor processer, der beder meget. Den pr\u00f8ver at give mindre til dem, der beder om mere. Store virtuelle maskiner er en plage.\n<\/li>\n<li>En lille m\u00e6ngde steal kan v\u00e6re normalt og uden paravirtualisering (under hensyntagen til belastningen inden i den virtuelle maskine, naboernes belastningskarakteristika, fordeling af belastningen over tr\u00e5de og andre faktorer).\n<\/li>\n<li>Hvis du vil finde ud af steal i et specifikt system, er du n\u00f8dt til at unders\u00f8ge forskellige muligheder, indsamle m\u00e5linger, grundigt analysere dem og t\u00e6nke over, hvordan man j\u00e6vnt fordeler belastningen. Der kan v\u00e6re afvigelser fra alle tilf\u00e6lde, som skal bekr\u00e6ftes eksperimentelt eller unders\u00f8ges i kernen debugger.\n<\/li>\n<\/ol>\n<p>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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: Hvem stj\u00e6ler CPU-tid fra virtuelle maskiner | ProHoster","description":"Hej!","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/32331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=32331"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/24147"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=32331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=32331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=32331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}