Hallo! Ek wil jou in eenvoudige terme vertel van die meganika van steel binne virtuele masjiene en van 'n paar nie-voor die hand liggend artefakte wat ons daarin geslaag het om uit te vind tydens die navorsing, waarin ek moes duik as 'n tegniese direkteur van 'n wolkplatform . Die platform loop op KVM.
SVE-steeltyd is die tyd waartydens die virtuele masjien nie verwerkerhulpbronne vir die uitvoering daarvan ontvang nie. Hierdie tyd word slegs in gasbedryfstelsels in virtualiseringsomgewings getel. Die redes vir waarheen hierdie mees toegekende hulpbronne gaan, soos in die lewe, is baie vaag. Maar ons het besluit om dit uit te vind, en het selfs 'n aantal eksperimente uitgevoer. Dit is nie dat ons nou alles van steel weet nie, maar ons sal jou nou iets interessants vertel.
1. Wat is steel
Dus, steel is 'n maatstaf wat 'n gebrek aan verwerkertyd vir prosesse binne 'n virtuele masjien aandui. Soos beskryf Stealth is die tyd waartydens die hiperviseerder ander prosesse op die gasheer-bedryfstelsel uitvoer, alhoewel dit die virtuele masjienproses in tou gestel het vir uitvoering. Dit wil sê, steel word bereken as die verskil tussen die tyd wanneer die proses gereed is om uit te voer en die tyd wanneer die proses verwerkertyd toegeken word.
Die virtuele masjienkern ontvang die steelmetriek van die hipervisor. Terselfdertyd spesifiseer die hiperviser nie presies watter ander prosesse dit loop nie, dit sê eenvoudig "terwyl ek besig is, kan ek jou nie tyd gee nie." Op KVM is ondersteuning vir steelberekening bygevoeg . Daar is twee sleutelpunte hier:
- Die virtuele masjien leer oor steel van die hypervisor. Dit wil sê, uit die oogpunt van verliese, vir prosesse op die virtuele masjien self is dit 'n indirekte meting wat aan verskeie vervormings onderhewig kan wees.
- Die hiperviser deel nie inligting met die virtuele masjien oor wat dit nog doen nie - die belangrikste ding is dat dit nie tyd daaraan wy nie. As gevolg hiervan kan die virtuele masjien self nie vervormings in die steelaanwyser opspoor nie, wat deur die aard van mededingende prosesse beoordeel kan word.
2. Wat raak steel
2.1. Steel berekening
In wese word steel ongeveer dieselfde as die normale SVE-gebruikstyd bereken. Daar is nie veel inligting oor hoe herwinning oorweeg word nie. Waarskynlik omdat die meeste mense hierdie vraag as voor die hand liggend beskou. Maar hier is ook slaggate. Om jouself met hierdie proses vertroud te maak, kan jy lees : jy sal leer oor baie nuanses by die berekening van benutting en oor situasies wanneer hierdie berekening om die volgende redes foutief sal wees:
- Die verwerker oorverhit, wat veroorsaak dat siklusse oorslaan.
- Aktiveer/deaktiveer turbo-hupstoot, wat die verwerker-klokfrekwensie verander.
- 'n Verandering in die lengte van die tydsny wat plaasvind wanneer verwerkerkragbesparende tegnologieë soos SpeedStep gebruik word.
- Die probleem met die berekening van die gemiddelde: om een minuut-benutting op 80% te skat, kan 'n korttermyn-uitbarsting van 100% verberg.
- 'n Spinslot veroorsaak dat die verwerker herwin word, maar die gebruikerproses sien geen vordering in die uitvoering daarvan nie. Gevolglik sal die berekende verwerkerbenutting deur die proses honderd persent wees, alhoewel die proses nie fisies verwerkertyd sal verbruik nie.
Ek het nie 'n artikel gevind wat 'n soortgelyke berekening vir steel beskryf nie (as jy weet, deel dit in die kommentaar). Maar, te oordeel aan die bronkode, is die berekeningsmeganisme dieselfde as vir herwinning. Eenvoudig, 'n ander teller word in die kern bygevoeg, direk vir die KVM-proses (virtuele masjienproses), wat die duur van die KVM-proses tel wat wag vir SVE-tyd. Die teller neem inligting oor die verwerker uit sy spesifikasie en kyk of al sy regmerkies deur die virtuele masjienproses gebruik word. As dit al is, neem ons aan dat die verwerker slegs met die virtuele masjienproses besig was. Andersins, lig ons in dat die verwerker iets anders doen, steel verskyn.
Die steeltelproses is onderhewig aan dieselfde probleme as gereelde herwinningstelling. Om nie te sê dat sulke probleme dikwels voorkom nie, maar dit lyk ontmoedigend.
2.2. Tipes virtualisasie op KVM
In die breë gesproke is daar drie tipes virtualisasie, wat almal deur KVM ondersteun word. Die meganisme van diefstal kan afhang van die tipe virtualisering.
Uitsaai. In hierdie geval vind die werking van die virtuele masjienbedryfstelsel met fisiese hipervisortoestelle so iets plaas:
- Die gasbedryfstelsel stuur 'n opdrag na sy gastoestel.
- Die gastoestelbestuurder ontvang die opdrag, genereer 'n versoek vir die toestel se BIOS en stuur dit na die hipervisor.
- Die hipervisor-proses vertaal bevel na bevel vir die fisiese toestel, wat dit onder andere veiliger maak.
- Die fisiese toestelbestuurder aanvaar die gewysigde opdrag en stuur dit na die fisiese toestel self.
- Die resultate van die uitvoering van opdragte gaan terug op dieselfde pad.
Die voordeel van vertaling is dat dit jou toelaat om enige toestel na te boots en nie spesiale voorbereiding van die bedryfstelselkern vereis nie. Maar jy moet eerstens hiervoor betaal.
Hardeware virtualisering. In hierdie geval verstaan die toestel op hardewarevlak opdragte van die bedryfstelsel. Dit is die vinnigste en beste manier. Maar dit word ongelukkig nie deur alle fisiese toestelle, hiperviseerders en gasbedryfstelsels ondersteun nie. Tans is die hooftoestelle wat hardewarevirtualisering ondersteun, verwerkers.
Paravirtualisering. Die mees algemene opsie vir toestelvirtualisering op KVM en oor die algemeen die mees algemene virtualisasiemodus vir gasbedryfstelsels. Die eienaardigheid daarvan is dat werk met sommige hipervisor-substelsels (byvoorbeeld met die netwerk- of skyfstapel) of toekenning van geheuebladsye geskied met behulp van die hipervisor-API, sonder om laevlak-opdragte te vertaal. Die nadeel van hierdie virtualiseringsmetode is dat die gasbedryfstelselkern gewysig moet word sodat dit met die hipervisor kan kommunikeer deur hierdie API te gebruik. Maar dit word gewoonlik opgelos deur spesiale drywers op die gasbedryfstelsel te installeer. In KVM word hierdie API genoem .
Met paravirtualisering, in vergelyking met uitsaai, word die pad na die fisiese toestel aansienlik verminder deur opdragte direk vanaf die virtuele masjien na die hipervisor-proses op die gasheer te stuur. Dit laat jou toe om die uitvoering van alle instruksies binne die virtuele masjien te bespoedig. In KVM word dit gedoen deur die virtio API, wat net vir sekere toestelle werk, soos 'n netwerk- of skyfadapter. Dit is hoekom virtio-bestuurders binne virtuele masjiene geïnstalleer word.
Die nadeel van hierdie versnelling is dat nie alle prosesse wat binne die virtuele masjien loop, daarin bly nie. Dit skep 'n paar spesiale effekte wat kan lei tot kuit op steel. Ek beveel aan om 'n gedetailleerde studie van hierdie kwessie met .
2.3. "Berelike" skedulering
'n Virtuele masjien op 'n hypervisor is in werklikheid 'n gewone proses wat die wette van skedulering (hulpbronverspreiding tussen prosesse) in die Linux-kern gehoorsaam, so kom ons kyk dit van nader.
Linux gebruik die sogenaamde CFS, Completely Fair Scheduler, wat sedert kern 2.6.23 die verstekskeduleerder geword het. Om hierdie algoritme te verstaan, kan jy die Linux Kernel Architecture of die bronkode lees. Die essensie van CFS is om verwerkertyd tussen prosesse te versprei, afhangende van die duur van hul uitvoering. Hoe meer SVE-tyd 'n proses vereis, hoe minder SVE-tyd ontvang dit. Dit verseker dat alle prosesse "regverdig" uitgevoer word - sodat een proses nie voortdurend alle verwerkers beset nie, en ander prosesse ook kan uitvoer.
Soms lei hierdie paradigma tot interessante artefakte. Langtydse Linux-gebruikers onthou waarskynlik die vries van 'n gewone teksredigeerder op 'n lessenaar terwyl hulpbron-intensiewe toepassings soos 'n samesteller uitgevoer word. Dit het gebeur omdat nie-hulpbron-intensiewe take in rekenaartoepassings meegeding het met hulpbron-intensiewe take, soos die samesteller. CFS dink dit is onregverdig, so dit stop die teksredigeerder van tyd tot tyd en laat die verwerker die samesteller se take hanteer. Dit is met behulp van 'n meganisme reggestel , maar baie ander kenmerke van die verspreiding van verwerkertyd tussen take het gebly. Eintlik is hierdie nie 'n storie oor hoe sleg alles in CFS is nie, maar 'n poging om die aandag daarop te vestig dat "regverdige" verspreiding van verwerkertyd nie die mees onbenullige taak is nie.
Nog 'n belangrike punt in die skeduleerder is preemption. Dit is nodig om die snikproses van die verwerker af te skop en ander te laat werk. Die uitwerpproses word kontekswisseling genoem. In hierdie geval word die hele konteks van die taak bewaar: die toestand van die stapel, registers, ens., waarna die proses gestuur word om te wag, en 'n ander een neem die plek daarvan in. Dit is 'n duur operasie vir die bedryfstelsel en word selde gebruik, maar daar is niks inherent fout daarmee nie. Gereelde kontekswisseling kan 'n probleem in die bedryfstelsel aandui, maar gewoonlik is dit deurlopend en dui niks spesifiek aan nie.
So 'n lang storie is nodig om een feit te verduidelik: hoe meer verwerkerhulpbronne 'n proses probeer verbruik in 'n eerlike Linux-skeduleerder, hoe vinniger sal dit gestop word sodat ander prosesse ook kan werk. Of dit korrek is of nie, is 'n komplekse vraag wat onder verskillende vragte verskillend opgelos kan word. In Windows was die skeduleerder tot onlangs gefokus op prioriteitsverwerking van lessenaartoepassings, wat kan veroorsaak dat agtergrondprosesse vries. Sun Solaris het vyf verskillende klasse skeduleers gehad. Toe ons virtualisering van stapel gestuur het, het ons 'n sesde een bygevoeg, , omdat die vorige vyf nie voldoende met Solaris Zones-virtualisering gewerk het nie. Ek beveel aan om 'n gedetailleerde studie van hierdie kwessie te begin met boeke soos of .
2.4. Hoe om steel te monitor?
Monitering van steel binne 'n virtuele masjien, soos enige ander verwerker-metriek, is eenvoudig: jy kan enige verwerker-metriek-instrument gebruik. Die belangrikste ding is dat die virtuele masjien op Linux is. Om een of ander rede verskaf Windows nie hierdie inligting aan sy gebruikers nie. 🙁
Uitvoer van die boonste opdrag: besonderhede van die verwerkerlading, in die mees regterkantste kolom - steel
Die moeilikheid ontstaan wanneer hierdie inligting van die hipervisor probeer verkry word. Jy kan probeer om steel op die gasheermasjien te voorspel, byvoorbeeld deur die Load Average (LA) parameter te gebruik - die gemiddelde waarde van die aantal prosesse wat in die uitvoering wag. Die metode om hierdie parameter te bereken is nie eenvoudig nie, maar in die algemeen, as LA genormaliseer deur die aantal verwerkerdrade meer as 1 is, dui dit aan dat die Linux-bediener met iets oorlaai is.
Waarvoor wag al hierdie prosesse? Die voor die hand liggende antwoord is die verwerker. Maar die antwoord is nie heeltemal korrek nie, want soms is die verwerker gratis, maar LA gaan van skaal af. Onthou . Dieselfde kan gebeur met 'n skyf en ander invoer-/afvoertoestelle. Maar in werklikheid kan prosesse wag vir die einde van enige slot, hetsy fisies, geassosieer met 'n I/O-toestel, of logies, soos 'n mutex. Dit sluit ook sluiting in op die vlak van hardeware (dieselfde reaksie vanaf die skyf), of logika (die sogenaamde sluitprimitiewe, wat 'n klomp entiteite insluit, mutex adaptive en spin, semafore, toestandsveranderlikes, rw-slotte, ipc-slotte ...).
Nog 'n kenmerk van LA is dat dit as 'n bedryfstelselgemiddeld beskou word. Byvoorbeeld, 100 prosesse ding mee om een lêer, en dan LA=50. So 'n groot waarde wil blykbaar aandui dat die bedryfstelsel sleg is. Maar vir ander krom geskrewe kode, kan dit 'n normale toestand wees, ten spyte van die feit dat net dit sleg is, en ander prosesse in die bedryfstelsel ly nie.
As gevolg van hierdie gemiddeld (en in nie minder nie as 'n minuut), is die bepaling van enigiets deur die LA-aanwyser nie die mees lonende taak nie, met baie onsekere resultate in spesifieke gevalle. As jy dit probeer uitpluis, sal jy vind dat artikels op Wikipedia en ander beskikbare bronne slegs die eenvoudigste gevalle beskryf, sonder 'n diepgaande verduideliking van die proses. Ek stuur weer vir almal wat belangstel, - volg die skakels hieronder. Wie is te lui om Engels te praat - .
3. Spesiale effekte
Kom ons kyk nou na die hoofgevalle van steel wat ons teëgekom het. Ek sal jou vertel hoe hulle uit al die bogenoemde volg en hoe dit verband hou met die aanwysers op die hiperviser.
Herwinning. Die eenvoudigste en mees algemene: die hipervisor is hergebruik. Inderdaad, daar is baie lopende virtuele masjiene, hoë verwerkerverbruik binne hulle, baie kompetisie, LA-gebruik is meer as 1 (genormaliseer deur verwerkerdrade). Alles binne alle virtuele masjiene vertraag. Steel wat vanaf die hipervisor oorgedra word, groei ook, dit is nodig om die vrag te herverdeel of iemand af te skakel. Oor die algemeen is alles logies en verstaanbaar.
Paravirtualisering teenoor enkelgevalle. Daar is net een virtuele masjien op die hipervisor; dit verbruik 'n klein deel daarvan, maar produseer 'n groot I/O-lading, byvoorbeeld op skyf. En van iewers af verskyn 'n klein steel daarin, tot 10% (soos deur verskeie eksperimente getoon).
Die saak is interessant. Steal verskyn hier juis as gevolg van blokkering op die vlak van geparavirtualiseerde bestuurders. 'n Onderbreking word binne die virtuele masjien geskep, deur die bestuurder verwerk en na die hipervisor gestuur. As gevolg van die onderbrekingshantering op die hypervisor, lyk dit vir die virtuele masjien soos 'n gestuurde versoek, dit is gereed vir uitvoering en wag vir die verwerker, maar dit kry nie verwerkertyd nie. Die virtuele meisie dink dat hierdie tyd gesteel is.
Dit gebeur op die oomblik dat die buffer gestuur word, dit gaan in die kernspasie van die hipervisor in, en ons begin daarvoor wag. Alhoewel, uit die oogpunt van die virtuele masjien, moet hy dadelik terugkeer. Daarom, volgens die steel berekening algoritme, word hierdie tyd as gesteel beskou. Heel waarskynlik, in hierdie situasie kan daar ander meganismes wees (byvoorbeeld die verwerking van ander stelsel-oproepe), maar hulle behoort nie veel anders te wees nie.
Skeduleerder teenoor hoogs gelaaide virtuele masjiene. Wanneer een virtuele masjien meer ly aan steel as ander, is dit as gevolg van die skeduleerder. Hoe meer 'n proses die verwerker laai, hoe gouer sal die skeduleerder dit uitskop sodat die ander ook kan werk. As die virtuele masjien min verbruik, sal dit skaars sien steel: sy proses het eerlik gesit en wag, ons moet dit meer tyd gee. As 'n virtuele masjien die maksimum las op al sy kerne produseer, word dit dikwels uit die verwerker geskop en probeer hulle om dit nie baie tyd te gee nie.
Dit is selfs erger wanneer prosesse binne die virtuele masjien meer verwerker probeer kry omdat hulle nie dataverwerking kan hanteer nie. Dan sal die bedryfstelsel op die hipervisor, as gevolg van eerlike optimalisering, al hoe minder verwerkertyd verskaf. Hierdie proses vind plaas soos 'n stortvloed, en steel spring na die lug, hoewel ander virtuele masjiene dit dalk skaars agterkom. En hoe meer kerne, hoe erger die geaffekteerde masjien. Kortom, hoogs gelaaide virtuele masjiene met baie kerne ly die meeste.
Lae LA, maar daar word gesteel. As LA ongeveer 0,7 is (dit wil sê, die hiperviser blyk te wees onderlaai), maar steel word waargeneem binne individuele virtuele masjiene:
- Die opsie met paravirtualisering wat reeds hierbo beskryf is. Die virtuele masjien kan statistieke ontvang wat steel aandui, hoewel die hiperviser goed is. Volgens die resultate van ons eksperimente oorskry hierdie steelopsie nie 10% nie en behoort dit nie 'n beduidende impak op die werkverrigting van toepassings binne die virtuele masjien te hê nie.
- Die LA-parameter is verkeerd bereken. Meer presies, op elke spesifieke oomblik word dit korrek bereken, maar as dit oor een minuut gemiddeld word, blyk dit onderskat te word. Byvoorbeeld, as een virtuele masjien per derde van die hiperviser al sy verwerkers vir presies 'n halwe minuut verbruik, dan sal LA per minuut op die hipervisor 0,15 wees; vier sulke virtuele masjiene wat gelyktydig werk, sal 0,6 gee. En die feit dat daar vir 'n halwe minuut op elkeen van hulle 'n wilde steel teen 25% volgens die LA-aanwyser was, kan nie meer uitgehaal word nie.
- Weereens, as gevolg van die skeduleerder wat besluit het dat iemand te veel eet en daardie iemand laat wag het. Intussen sal ek die konteks verander, onderbrekings hanteer en na ander belangrike stelseldinge omsien. Gevolglik sien sommige virtuele masjiene geen probleme nie, terwyl ander ernstige prestasie-agteruitgang ervaar.
4. Ander vervormings
Daar is nog 'n miljoen redes om die billike opbrengs van verwerkertyd op 'n virtuele masjien te verdraai. Byvoorbeeld, hiperthreading en NUMA stel probleme in berekeninge in. Hulle verwar die keuse van kern vir die uitvoering van die proses heeltemal, want die skeduleerder gebruik koëffisiënte - gewigte, wat die berekening nog moeiliker maak wanneer die konteks verander word.
Daar is vervormings as gevolg van tegnologieë soos turbo-hupstoot of, omgekeerd, energiebesparingsmodus, wat, wanneer benutting bereken word, die frekwensie of selfs die tydstuk op die bediener kunsmatig kan verhoog of verlaag. Om turbo-hupstoot te aktiveer, verminder die werkverrigting van een verwerkerdraad as gevolg van 'n toename in die werkverrigting van 'n ander. Op hierdie oomblik word inligting oor die huidige verwerkerfrekwensie nie na die virtuele masjien oorgedra nie, en dit glo dat iemand sy tyd steel (dit het byvoorbeeld 2 GHz aangevra, maar die helfte daarvan ontvang).
Oor die algemeen kan daar baie redes vir vervorming wees. Jy kan dalk iets anders op 'n spesifieke stelsel vind. Dit is beter om te begin met die boeke waarna ek hierbo skakels gegee het, en om statistieke van die hiperviser af te haal deur nutsprogramme soos perf, sysdig, systemtap, waarvan .
5. Gevolgtrekkings
- 'n mate van steel kan voorkom as gevolg van paravirtualisering, en dit kan as normaal beskou word. Hulle skryf op die internet dat hierdie waarde 5-10% kan wees. Hang af van die toepassings binne die virtuele masjien en van die las wat dit op sy fisiese toestelle plaas. Hier is dit belangrik om aandag te gee aan hoe toepassings binne virtuele masjiene voel.
- Die verhouding van die las op die hypervisor en steel binne die virtuele masjien is nie altyd duidelik onderling verwant nie; beide skattings van steel kan in spesifieke situasies onder verskillende vragte foutief wees.
- Die skeduleerder het 'n slegte houding teenoor prosesse wat baie vra. Hy probeer minder gee vir diegene wat vir meer vra. Groot virtuele masjiene is boos.
- 'N bietjie steel kan die norm wees, selfs sonder paravirtualisering (met inagneming van die las binne die virtuele masjien, die kenmerke van die vrag van bure, vragverspreiding oor drade en ander faktore).
- As jy steel in 'n spesifieke stelsel wil uitvind, moet jy verskeie opsies ondersoek, statistieke versamel, dit noukeurig ontleed en dink oor hoe om die vrag eweredig te versprei. Afwykings van enige gevalle is moontlik, wat eksperimenteel bevestig moet word of in die kernontfouter gekyk moet word.
Bron: will.com