Kaixo! Makina birtualen barruan lapurtzearen mekanikari buruz eta bere ikerketan zehar aurkitu genituen artefaktu ez-agerikoei buruz hitz egin nahi dizut, hodeiko plataforma bateko zuzendari tekniko gisa murgildu behar izan nituenak. . Plataformak KVMn exekutatzen du.
CPU lapurtzeko denbora makina birtualak bere exekuziorako prozesadorearen baliabideak jasotzen ez dituen denbora da. Denbora hori birtualizazio-inguruneetako sistema eragile gonbidatuetan bakarrik zenbatuko da. Gehien esleitutako baliabide horiek nora doazen arrazoiak, bizitzan bezala, oso lausoak dira. Baina hori asmatzea erabaki genuen, eta hainbat esperimentu ere egin genituen. Ez da orain lapurretaz dena dakigula, baina zerbait interesgarria kontatuko dizuegu orain.
1. Zer da lapurreta
Beraz, lapurtzea makina birtual baten barruan prozesuetarako prozesadore-denbora falta adierazten duen metrika da. Deskribatu bezala Stealth hipervisoreak ostalari OSan beste prozesu batzuk exekutatzen dituen denbora da, nahiz eta makina birtualaren prozesua exekutatzeko ilaran jarri duen. Hau da, lapurtzea prozesua exekutatzeko prest dagoen denboraren eta prozesua prozesadorearen denbora esleitzen zaion denboraren arteko diferentzia gisa kalkulatzen da.
Makina birtualeko nukleoak hipervisorearen lapurreta metrika jasotzen du. Aldi berean, hipervisoreak ez du zehatz-mehatz zehazten zein beste prozesu exekutatzen ari den, besterik gabe esaten du "lanpetuta nagoen bitartean, ezin dizut denborarik eman". KVM-n, lapurreta kalkulatzeko laguntza gehitu da . Bi puntu gako daude hemen:
- Makina birtualak hipervisorearen lapurretaz ikasten du. Hau da, galeren ikuspuntutik, makina birtualean bertan dauden prozesuetarako zeharkako neurketa da, hainbat distortsio jasan ditzakeena.
- Hipervisoreak ez du informaziorik partekatzen makina birtualarekin beste egiten ari denari buruz - gauza nagusia da ez diola denborarik eskaintzen. Hori dela eta, makina birtualak berak ezin du lapurtzen adierazlean distortsiorik hauteman, prozesu lehiakideen izaeraren arabera ebaluatu daitezkeenak.
2. Lapurreta eragiten duena
2.1. Lapurtu kalkulua
Funtsean, lapurreta CPU erabilera-denbora arruntaren berdina kalkulatzen da. Ez dago informazio asko birziklatzeari buruz. Seguruenik, jende gehienak galdera hau begi-bistakoa iruditzen zaiolako. Baina hemen ere badaude zuloak. Prozesu hau ezagutzeko, irakurri dezakezu : erabilera kalkulatzerakoan Γ±abardura asko ezagutuko dituzu eta arrazoi hauengatik kalkulu hori okerra izango den egoerei buruz:
- Prozesadorea gehiegi berotzen da, eta zikloak saltatzen ditu.
- Gaitu/desgaitu turbo boost, prozesadorearen erlojuaren maiztasuna aldatzen duena.
- SpeedStep bezalako prozesadorearen energia aurrezteko teknologiak erabiltzean gertatzen den denbora-tartearen iraupena.
- Batez bestekoa kalkulatzeko arazoa: minutu bateko erabilera %80an kalkulatzeak %100eko epe laburreko leherketa ezkutatu dezake.
- Biratze-blokeoak prozesadorea berreskuratzea eragiten du, baina erabiltzailearen prozesuak ez du aurrerapenik ikusten bere exekuzioan. Ondorioz, prozesuak kalkulatutako prozesadorearen erabilera ehuneko ehunekoa izango da, nahiz eta prozesuak ez duen fisikoki prozesadorearen denbora kontsumituko.
Ez dut lapurretarako antzeko kalkulu bat deskribatzen duen artikulurik aurkitu (badakizu, partekatu iruzkinetan). Baina, iturburu-kodea ikusita, kalkulu-mekanismoa birziklapenaren berdina da. Besterik gabe, beste kontagailu bat gehitzen da nukleoan, zuzenean KVM prozesurako (makina birtualaren prozesua), zeinak PUZaren denboraren zain dagoen KVM prozesuaren iraupena zenbatzen duena. Kontagailuak prozesadoreari buruzko informazioa hartzen du bere zehaztapenetatik eta bere tick guztiak makina birtualeko prozesuak erabiltzen dituen egiaztatzen du. Hori dena bada, prozesadorea makina birtualeko prozesuarekin bakarrik okupatu zela suposatuko dugu. Bestela, prozesadorea beste zerbait egiten ari zela jakinarazten dugu, lapurreta agertu zen.
Lapurreta zenbatzeko prozesuak ohiko birziklapenaren zenbaketarekin dituen arazo berdinak ditu. Ez esan nahi horrelako arazoak askotan agertzen direnik, baina etsigarriak dirudite.
2.2. Birtualizazio motak KVMn
Oro har, hiru birtualizazio mota daude, guztiak KVM-k onartzen dituena. Lapurreta gertatzeko mekanismoa birtualizazio motaren araberakoa izan daiteke.
Broadcast. Kasu honetan, makina birtualaren sistema eragilearen funtzionamendua hipervisor gailu fisikoekin honela gertatzen da:
- Sistema eragile gonbidatuak komando bat bidaltzen dio bere gailu gonbidatuari.
- Gonbidatutako gailuaren kontrolatzaileak komandoa jasotzen du, gailuaren BIOSrako eskaera bat sortzen du eta hipervisorera bidaltzen du.
- Hipervisor-prozesuak komandoa komando bihurtzen du gailu fisikorako, eta, besteak beste, seguruagoa da.
- Gailu fisikoaren kontrolatzaileak aldatutako komandoa onartzen du eta gailu fisikora bera bidaltzen du.
- Aginduak exekutatzeko emaitzak bide beretik doaz atzera.
Itzulpenaren abantaila da edozein gailu emulatzeko aukera ematen duela eta ez duela sistema eragilearen nukleoaren prestaketa berezirik behar. Baina hori ordaindu behar da, lehenik eta behin, abiaduran.
Hardwarearen birtualizazioa. Kasu honetan, hardware mailan gailuak sistema eragilearen komandoak ulertzen ditu. Hau da modurik azkarrena eta onena. Baina, zoritxarrez, ez dute gailu fisiko, hipervisore eta sistema eragile gonbidatu guztiek onartzen. Gaur egun, hardware birtualizazioa onartzen duten gailu nagusiak prozesadoreak dira.
Parabirtualizazioa. KVMn gailua birtualizatzeko aukera ohikoena eta, oro har, sistema eragile gonbidatuentzako birtualizazio modu ohikoena. Bere berezitasuna da hipervisoreko azpisistema batzuekin lan egitea (adibidez, sarearekin edo disko pilarekin) edo memoria orrien esleipena hipervisorearen APIa erabiliz gertatzen dela, behe-mailako komandoak itzuli gabe. Birtualizazio metodo honen desabantaila da sistema eragile gonbidatuaren nukleoa aldatu behar dela, API hau erabiliz hipervisorearekin komunikatu ahal izateko. Baina hau sistema eragile gonbidatuan kontrolatzaile bereziak instalatuz konpontzen da normalean. KVMn API honi deitzen zaio .
Parabirtualizazioarekin, igorpenarekin alderatuta, gailu fisikorako bidea nabarmen murrizten da makina birtualetik ostalariaren hipervisorearen prozesura komandoak zuzenean bidaliz. Honi esker, makina birtualen barruan dauden argibide guztien exekuzioa azkartu dezakezu. KVM-n, hori virtio APIak egiten du, gailu jakin batzuetan bakarrik funtzionatzen duena, hala nola sare edo disko egokitzaile batentzat. Horregatik instalatzen dira virtio kontrolatzaileak makina birtualen barruan.
Azelerazio honen alde txarra da makina birtualean exekutatzen diren prozesu guztiak ez direla haren barruan geratzen. Honek efektu berezi batzuk sortzen ditu, lapurretaren ondorioz sortu daitezkeenak. Arazo honen azterketa zehatza hastea gomendatzen dut .
2.3. "Azoka" programazioa
Hipervisoreko makina birtual bat, hain zuzen, Linux nukleoan programazioaren (prozesuen arteko baliabideen arteko banaketa) legeak betetzen dituen prozesu arrunt bat da, beraz, ikus dezagun hurbilagotik.
Linux-ek CFS deritzona erabiltzen du, Erabat Justu Programatzailea, 2.6.23 nukleotik aurrerako programatzaile lehenetsia bihurtu dena. Algoritmo hau ulertzeko, Linux Kernel Arkitektura edo iturburu kodea irakur dezakezu. CFSren funtsa prozesadorearen denbora prozesuen artean banatzea da, haien exekuzioaren iraupenaren arabera. Prozesu batek zenbat eta CPU denbora gehiago behar, orduan eta PUZ denbora gutxiago jasotzen du. Horrek prozesu guztiak "nahiko" exekutatzen direla ziurtatzen du, prozesu batek prozesadore guztiak etengabe okupatu ez ditzan eta beste prozesu batzuk ere exekutatu daitezke.
Batzuetan paradigma honek artefaktu interesgarrietara eramaten du. Aspaldiko Linux-eko erabiltzaileek ziurrenik gogoratzen dute mahaigainean ohiko testu-editore bat izoztu izana, baliabide asko erabiltzen dituzten aplikazioak exekutatzen ari diren bitartean, hala nola konpiladore bat. Hau gertatu da mahaigaineko aplikazioetako baliabideak ez dituzten zereginak baliabide askoko zereginekin lehiatzen zirelako, konpilatzailea adibidez. CFS-k uste du hori bidegabea dela, beraz, aldian-aldian testu-editorea gelditzen du eta prozesadoreari uzten dio konpilatzailearen zereginak kudeatzen. Hau mekanismo baten bidez zuzendu zen , baina zereginen artean prozesadore-denboraren banaketaren beste ezaugarri asko geratu ziren. Egia esan, hau ez da CFS-en dena zein txarra den buruzko istorio bat, prozesadorearen denboraren banaketa "bidezkoa" ez dela zeregin hutsala ez dela arreta erakartzeko saiakera baizik.
Antolatzailean beste puntu garrantzitsu bat prebentzioa da. Hau beharrezkoa da prozesadoretik irrifartze-prozesua kanporatzeko eta besteei lan egiteko. Ejekzio-prozesuari testuinguru-aldaketa deritzo, prozesadorearen testuinguru-aldaketa. Kasu honetan, zereginaren testuinguru osoa gordetzen da: pilaren egoera, erregistroak, etab., ondoren prozesua itxarotera bidaltzen da eta beste batek hartzen du bere lekua. Eragiketa garestia da sistema eragilearentzat eta oso gutxitan erabiltzen da, baina ez dago ezer okerrik. Testuinguru-aldaketa maiz aldatzeak sistema eragilean arazo bat adieraz dezake, baina normalean etengabea da eta ez du ezer berezirik adierazten.
Hain istorio luze bat behar da datu bat azaltzeko: zenbat eta prozesadore-baliabide gehiago kontsumitu saiatu Linux-en programatzaile zintzo batean, orduan eta azkarrago geldituko da, beste prozesu batzuek ere funtziona dezaten. Hau zuzena den ala ez galdera konplexua da, karga ezberdinetan modu ezberdinean ebatzi daitekeena. Windows-en, duela gutxi arte, programatzailea mahaigaineko aplikazioen lehentasunezko prozesamenduan zentratzen zen, eta horrek atzeko planoko prozesuak izoztea eragin zezakeen. Sun Solaris-ek bost programatzaile klase ezberdin zituen. Birtualizazioa martxan jarri genuenean, seigarren bat gehitu genuen, , aurreko bostek ez zutelako behar bezala funtzionatu Solaris Zones birtualizazioarekin. Horrelako liburuekin gai honen azterketa zehatza hastea gomendatzen dut edo .
2.4. Nola kontrolatu lapurreta?
Makina birtual baten barruan lapurreta kontrolatzea, beste edozein prozesadore-neurri bezala, erraza da: edozein prozesadore-neurri-tresna erabil dezakezu. Gauza nagusia da makina birtuala Linux-en dagoela. Arrazoiren batengatik, Windows-ek ez die informazio hori ematen erabiltzaileei. π
Goiko komandoaren irteera: prozesadorearen kargaren xehetasunak, eskuineko zutabean - lapurtu
Informazio hori hipervisorearengandik lortzen saiatzean sortzen da zailtasuna. Ostalari makinan lapurreta iragartzen saia zaitezke, adibidez, Load Average (LA) parametroa erabiliz, exekuzio-ilaran zain dauden prozesu kopuruaren batez besteko balioa. Parametro hau kalkulatzeko metodoa ez da erraza, baina, oro har, prozesadorearen hari kopuruaren arabera normalizatutako LA 1 baino gehiago bada, horrek adierazten du Linux zerbitzaria zerbaitez gainkargatuta dagoela.
Zeren zain daude prozesu hauek guztiak? Ageriko erantzuna prozesadorea da. Baina erantzuna ez da guztiz zuzena, batzuetan prozesadorea doakoa baita, baina LA eskalatik kanpo doa. Gogoratu . Gauza bera gerta daiteke disko batekin eta beste sarrera/irteera gailu batzuekin. Baina, hain zuzen ere, prozesuek edozein blokeoren amaiera arte itxaron dezakete, bai fisikoa, I/O gailu bati lotutakoa, edo logikoa, adibidez, mutex bat. Honek hardware mailan blokeatzea ere barne hartzen du (diskoaren erantzun bera), edo logika (blokeo primitiboak deiturikoak, entitate mordoa barne hartzen dituena, mutex moldagarria eta spin, semaforoak, baldintza aldagaiak, rw blokeoak, ipc blokeoak). ...).
LAren beste ezaugarri bat sistema eragilearen batez bestekotzat hartzen dela da. Adibidez, 100 prozesu ari dira lehian fitxategi baterako, eta gero LA=50. Balio hain handi batek sistema eragilea txarra dela adieraziko luke. Baina gaizki idatzitako beste kode batzuen kasuan, egoera normala izan daiteke, bakarrik txarra den arren, eta sistema eragileko beste prozesu batzuek ez dute jasaten.
Batez besteko hau dela eta (eta minutu batean baino gutxiagoan), LA adierazlearen bidez ezer zehaztea ez da lan aberasgarriena, kasu zehatzetan oso emaitza zalantzagarriak izanik. Hori asmatzen saiatzen bazara, aurkituko duzu Wikipediako artikuluek eta eskura dauden beste baliabide batzuek kasu errazenak soilik deskribatzen dituztela, prozesuaren azalpen sakonik gabe. Interesa duten guztiak bidaltzen ditut berriro, - jarraitu beheko estekak. Nor da alferra ingelesez hitz egiteko - .
3. Efektu bereziak
Ikus ditzagun orain topatu ditugun lapurreta kasu nagusiak. Esango dizut nola jarraitzen duten aurreko guztia eta nola erlazionatzen diren hipervisoreko adierazleekin.
Birziklapena. Errazena eta ohikoena: hipervisorea berrerabili da. Izan ere, makina birtual asko martxan daude, prozesadore-kontsumo handia haien barruan, lehia handia, LA erabilera 1 baino gehiago da (prozesadorearen hariek normalizatuta). Makina birtual guztien barruan dagoen guztia moteltzen da. Hipervisoretik transmititutako lapurreta ere hazten ari da, beharrezkoa da karga birbanatzea edo norbait itzaltzea. Oro har, dena logikoa eta ulergarria da.
Parabirtualizazioa vs. Instantzia bakarrak. Hipervisorean makina birtual bakarra dago; zati txiki bat kontsumitzen du, baina I/O karga handia sortzen du, adibidez diskoan. Eta nonbaitetik lapurreta txiki bat agertzen da bertan, %10eraino (hainbat esperimentuk erakusten dutenez).
Kasua interesgarria da. Lapurtzea hemen agertzen da, hain zuzen, parabirtualizatutako gidarien mailan blokeatzeagatik. Eten bat sortzen da makina birtualean, gidariak prozesatu eta hipervisorera bidaltzen du. Hipervisorean eten-kudeaketaren ondorioz, makina birtualerako bidalitako eskaera baten itxura du, exekutatzeko prest dago eta prozesadorearen zain dago, baina ez zaio prozesadorearen denborarik ematen. Neska birtualak uste du denbora hau lapurtu dutela.
Buffer-a bidaltzen den momentuan gertatzen da hau, hipervisorearen nukleoan sartzen da eta horren zain hasten gara. Nahiz eta, makina birtualaren ikuspuntutik, berehala itzuli beharko luke. Hori dela eta, lapurreta kalkulatzeko algoritmoaren arabera, denbora hau lapurtutzat hartzen da. Seguruenik, egoera honetan beste mekanismo batzuk egon daitezke (adibidez, beste sistema-dei batzuk prozesatzea), baina ez lukete oso desberdinak izan behar.
Antolatzailea eta oso kargatutako makina birtualak. Makina birtual batek besteek baino gehiago lapurreta pairatzen dutenean, hori programatzaileari dagokio. Prozesu batek zenbat eta gehiago kargatu prozesadorea, orduan eta lehenago kaleratuko du programatzaileak besteek ere lan egin dezaten. Makina birtualak gutxi kontsumitzen badu, nekez ikusiko du lapurreta: bere prozesua zintzotasunez eserita eta itxaron, denbora gehiago eman behar diogu. Makina birtual batek bere nukleo guztietan karga maximoa sortzen badu, askotan prozesadoretik kanporatzen da eta denbora asko ez ematen saiatzen dira.
Are okerragoa da makina birtualeko prozesuak prozesadore gehiago lortzen saiatzen direnean, datuen prozesamenduari aurre egin ezin diotelako. Orduan, hipervisoreko sistema eragileak, optimizazio zintzoa dela eta, gero eta prozesadorearen denbora gutxiago emango du. Prozesu hau elur-jausi baten moduan gertatzen da, eta lapurreta jauziak zerura, nahiz eta beste makina birtualek nekez nabarituko duten. Eta zenbat eta nukleo gehiago, orduan eta okerragoa izango da kaltetutako makina. Laburbilduz, oso kargatutako nukleo asko dituzten makina birtualek sufritzen dute gehien.
LA baxua, baina lapurreta dago. LA gutxi gorabehera 0,7 bada (hau da, hipervisorea gutxi gorabehera kargatuta dagoela dirudi), baina makina birtualen barnean lapurreta ikusten da:
- Gorago deskribatutako parabirtualizazioa duen aukera. Makina birtualak lapurreta adierazten duten neurketak jaso ditzake, hipervisora ββondo dagoen arren. Gure esperimentuen emaitzen arabera, lapurtzeko aukera honek ez du % 10a gainditzen eta ez luke eragin handirik izan behar makina birtualeko aplikazioen errendimenduan.
- LA parametroa gaizki kalkulatzen da. Zehatzago esanda, une zehatz bakoitzean behar bezala kalkulatzen da, baina minutu bateko batez bestekoa egiten denean gutxiesten da. Adibidez, hipervisorearen heren bakoitzeko makina birtual batek bere prozesadore guztiak minutu erdi batez kontsumitzen baditu, orduan hipervisorearen minutuko LA 0,15 izango da; aldi berean lan egiten duten halako lau makina birtualek 0,6 emango dute. Eta horietako bakoitzean minutu erdi batez LA adierazlearen arabera %25eko lapurreta basati bat egon zela ezin da gehiago atera.
- Berriz ere, norbaitek gehiegi jaten zuela eta norbaitek itxaroten utzi zuela erabaki zuen programatzaileak. Bitartean, testuingurua aldatuko dut, etenak kudeatuko ditut eta sistemako beste gauza garrantzitsu batzuk zainduko ditut. Ondorioz, makina birtual batzuek ez dute arazorik ikusten, eta beste batzuek errendimenduaren degradazio larria jasaten dute.
4. Beste distortsio batzuk
Makina birtual batean prozesadorearen denboraren itzulera zuzena desitxuratzeko milioi bat arrazoi gehiago daude. Adibidez, hyperthreading-ak eta NUMAk zailtasunak sartzen dituzte kalkuluetan. Prozesua exekutatzeko nukleoaren aukeraketa guztiz nahasten dute, planifikatzaileak koefizienteak - pisuak erabiltzen dituelako, eta horrek kalkulua are zailagoa egiten du testuingurua aldatzean.
Distortsioak daude turbo boost edo, alderantziz, energia aurrezteko modua bezalako teknologien ondorioz, zeinak, erabilera kalkulatzerakoan, zerbitzariaren maiztasuna edo denbora tartea artifizialki handitu edo txikitu ditzaketenak. Turbo boost gaitzeak prozesadorearen hari baten errendimendua murrizten du beste baten errendimendua handitu delako. Momentu honetan, egungo prozesadorearen maiztasunari buruzko informazioa ez da makina birtualera transmititzen, eta norbaitek denbora lapurtzen ari zaiola uste du (adibidez, 2 GHz eskatu zuen, baina erdia jaso zuen).
Oro har, distortsiorako arrazoi asko egon daitezke. Sistema jakin batean beste zerbait aurki dezakezu. Hobe da goiko estekak eman nizkion liburuetatik hastea eta hipervisorearen estatistikak berreskuratzea, besteak beste, perf, sysdig, systemtap bezalako utilitateak erabiliz. .
5. Ondorioak
- Parabirtualizazioa dela eta, lapurreta kopuru bat gerta daiteke, eta normaltzat jo daiteke. Interneten idazten dute balio hori %5-10 izan daitekeela. Makina birtualen barruan dauden aplikazioen eta bere gailu fisikoetan jartzen duen kargaren araberakoa da. Hemen garrantzitsua da aplikazioak makina birtualen barruan nola sentitzen diren erreparatzea.
- Hipervisoreko kargaren eta makina birtualaren barneko lapurtzearen arteko erlazioa ez dago beti elkarren artean argi eta garbi erlazionatuta; lapurreten estimazio biak okerrak izan daitezke karga ezberdinetan egoera zehatzetan.
- Antolatzaileak jarrera txarra du asko eskatzen duten prozesuekiko. Gehiago eskatzen dutenei gutxiago ematen saiatzen da. Makina birtual handiak gaiztoak dira.
- Lapurreta txiki bat ohikoa izan daiteke parabirtualizaziorik gabe ere (makina birtualaren barneko karga, auzokideen kargaren ezaugarriak, harien arteko karga banaketa eta beste faktore batzuk kontuan hartuta).
- Sistema zehatz batean lapurreta irudikatu nahi baduzu, hainbat aukera aztertu, metrikak bildu, arretaz aztertu eta karga uniformeki nola banatu pentsatu behar duzu. Edozein kasutan desbideratzeak posible dira, esperimentalki baieztatu edo nukleoaren arazketan aztertu behar direnak.
Iturria: www.habr.com