Saluton! Mi volas simple rakonti al vi pri la mekaniko de ŝtelado ene de virtualaj maŝinoj kaj pri kelkaj neevidentaj artefaktoj, kiujn ni sukcesis ekscii dum ĝia esplorado, en kiuj mi devis plonĝi kiel teknika direktoro de nuba platformo. . La platformo funkcias per KVM.
CPU ŝtela tempo estas la tempo dum kiu la virtuala maŝino ne ricevas procesorresursojn por sia ekzekuto. Ĉi tiu tempo nur kalkulas en gastaj operaciumoj en virtualaj medioj. La kialoj de kie ĉi tiuj plej asignitaj rimedoj iras, kiel en la vivo, estas tre neklaraj. Sed ni decidis eltrovi ĝin, kaj eĉ efektivigis kelkajn eksperimentojn. Ne estas ke ni nun scias ĉion pri ŝtelado, sed ni rakontos al vi ion interesan nun.
1. Kio estas ŝteli
Do, ŝteli estas metriko, kiu indikas mankon de procesora tempo por procezoj en virtuala maŝino. Kiel priskribite Stealth estas la tempo dum kiu la hiperviziero efektivigas aliajn procezojn sur la gastiga OS kvankam ĝi vicigis la virtualan maŝinan procezon por ekzekuto. Tio estas, ŝteli estas kalkulita kiel la diferenco inter la tempo kiam la procezo estas preta por efektivigi kaj la tempo kiam la procezo estas asignita procesortempo.
La virtuala maŝina kerno ricevas la ŝtelimetrikon de la hiperviziero. Samtempe, la hiperviziero ne precizigas precize kiajn aliajn procezojn ĝi funkcias, ĝi simple diras "dum mi estas okupata, mi ne povas doni al vi tempon." Sur KVM, subteno por ŝtela kalkulado estis aldonita al . Estas du ĉefaj punktoj ĉi tie:
- La virtuala maŝino lernas pri ŝtelado de la hiperviziero. Tio estas, el la vidpunkto de perdoj, por procezoj sur la virtuala maŝino mem tio estas nerekta mezurado, kiu povas esti submetita al diversaj misprezentoj.
- La hiperviziero ne dividas informojn kun la virtuala maŝino pri kio alia ĝi faras - la ĉefa afero estas, ke ĝi ne dediĉas tempon al ĝi. Pro tio, la virtuala maŝino mem ne povas detekti distordojn en la ŝtela indikilo, kiu povus esti taksita laŭ la naturo de konkurantaj procezoj.
2. Kio influas ŝteli
2.1. Ŝtelu kalkulon
Esence, ŝtelo estas kalkulita proksimume same kiel la normala CPU-uzotempo. Ne estas multe da informoj pri kiel oni konsideras recikladon. Probable ĉar plej multaj homoj konsideras ĉi tiun demandon evidenta. Sed ĉi tie ankaŭ estas kaptiloj. Por konatiĝi kun ĉi tiu procezo, vi povas legi : vi lernos pri multaj nuancoj dum kalkulo de utiligo kaj pri situacioj, kiam tiu kalkulo estos erara pro jenaj kialoj:
- La procesoro trovarmiĝas, igante ciklojn salti.
- Ebligu/malŝalti turbo-akcelon, kiu ŝanĝas la frekvencon de la procesoro.
- Ŝanĝo en la longeco de la tempotranĉaĵo, kiu okazas kiam oni uzas procesorajn energiŝparajn teknologiojn kiel SpeedStep.
- La problemo pri kalkulado de la mezumo: taksi unuminutan utiligon je 80% povas kaŝi mallongdaŭran eksplodon de 100%.
- Spinŝlosilo igas la procesoron esti reprenita, sed la uzantprocezo ne vidas ajnan progreson en sia ekzekuto. Kiel rezulto, la kalkulita procesoro-utiligo per la procezo estos centprocenta, kvankam la procezo ne fizike konsumos procesoran tempon.
Mi ne trovis artikolon priskribanta similan kalkulon por ŝtelo (se vi scias, dividu ĝin en la komentoj). Sed, se juĝante laŭ la fontkodo, la kalkulmekanismo estas la sama kiel por reciklado. Simple, alia nombrilo estas aldonita en la kerno, rekte por la KVM-procezo (virtuala maŝinprocezo), kiu kalkulas la daŭron de la KVM-procezo atendante CPU-tempon. La nombrilo prenas informojn pri la procesoro de sia specifo kaj kontrolas ĉu ĉiuj ĝiaj iksodoj estas utiligitaj per la virtuala maŝinprocezo. Se tio estas ĉio, tiam ni supozas, ke la procesoro estis nur okupita per la virtuala maŝina procezo. Alie, ni informas, ke la procesoro faris ion alian, ŝtelo aperis.
La ŝtela kalkula procezo estas submetata al la samaj problemoj kiel regula reciklada nombrado. Por ne diri, ke tiaj problemoj aperas ofte, sed ili aspektas malkuraĝigaj.
2.2. Tipoj de virtualigo sur KVM
Larĝe parolante, ekzistas tri specoj de virtualigo, ĉiuj el kiuj estas subtenataj de KVM. La mekanismo de ŝtela okazo povas dependi de la speco de virtualigo.
Elsendo. En ĉi tiu kazo, la funkciado de la virtuala maŝino operaciumo kun fizikaj hiperviziaj aparatoj okazas io kiel ĉi tio:
- La gastoperaciumo sendas komandon al sia gasta aparato.
- La gast-aparato-ŝoforo ricevas la komandon, generas peton por la aparato BIOS kaj sendas ĝin al la hiperviziero.
- La hipervizila procezo tradukas komandon al komando por la fizika aparato, farante ĝin, interalie, pli sekura.
- La fizika aparato-ŝoforo akceptas la modifitan komandon kaj sendas ĝin al la fizika aparato mem.
- La rezultoj de plenumado de komandoj iras reen laŭ la sama vojo.
La avantaĝo de tradukado estas, ke ĝi permesas kopii ajnan aparaton kaj ne postulas specialan preparadon de la operaciuma kerno. Sed vi devas pagi por tio, unue, rapide.
Aparataro virtualigo. En ĉi tiu kazo, la aparato ĉe la aparataro komprenas komandojn de la operaciumo. Ĉi tio estas la plej rapida kaj plej bona maniero. Sed, bedaŭrinde, ĝi ne estas subtenata de ĉiuj fizikaj aparatoj, hiperviziiloj kaj gastoperaciumoj. Nuntempe, la ĉefaj aparatoj, kiuj subtenas aparataron virtualigon, estas procesoroj.
Paravirtualigo. La plej ofta opcio por aparata virtualigo sur KVM kaj ĝenerale la plej ofta virtualiga reĝimo por gastoperaciumoj. Ĝia propreco estas, ke laboro kun iuj subsistemoj de hiperviziero (ekzemple, kun la reto aŭ disko stako) aŭ atribuo de memorpaĝoj okazas uzante la hiperviziero API, sen traduki malaltnivelaj komandoj. La malavantaĝo de ĉi tiu virtualiga metodo estas, ke la gastoperaciuma kerno devas esti modifita por ke ĝi povu komuniki kun la hiperviziero uzante ĉi tiun API. Sed ĉi tio kutime solvas instalante specialajn ŝoforojn sur la gastoperaciumo. En KVM ĉi tiu API estas nomita .
Kun paravirtualigo, kompare kun dissendado, la vojo al la fizika aparato estas signife reduktita sendante komandojn rekte de la virtuala maŝino al la hipervizila procezo sur la gastiganto. Ĉi tio permesas vin akceli la ekzekuton de ĉiuj instrukcioj ene de la virtuala maŝino. En KVM, tio estas farita de la virtio API, kiu funkcias nur por certaj aparatoj, kiel reto aŭ diskadaptilo. Tial virtio-ŝoforoj estas instalitaj ene de virtualaj maŝinoj.
La malavantaĝo de ĉi tiu akcelo estas, ke ne ĉiuj procezoj, kiuj funkcias ene de la virtuala maŝino, restas en ĝi. Ĉi tio kreas kelkajn specialajn efektojn, kiuj povas rezultigi generi sur ŝtelo. Mi rekomendas komenci detalan studon de ĉi tiu afero kun .
2.3. "Justa" planado
Virtuala maŝino sur hiperviziero estas, fakte, ordinara procezo, kiu obeas la leĝojn de planado (resursa distribuo inter procezoj) en la Linukso-kerno, do ni rigardu ĝin pli detale.
Linukso uzas la tielnomitan CFS, Completely Fair Scheduler, kiu fariĝis la defaŭlta planilo ekde la kerno 2.6.23. Por kompreni ĉi tiun algoritmon, vi povas legi la Linux Kernel Architecture aŭ la fontkodon. La esenco de CFS estas distribui procesoran tempon inter procezoj depende de la daŭro de ilia ekzekuto. Ju pli da CPU-tempo procezo postulas, des malpli da CPU-tempo ĝi ricevas. Ĉi tio certigas, ke ĉiuj procezoj estas ekzekutitaj "juste" - tiel ke unu procezo ne konstante okupas ĉiujn procesorojn, kaj aliaj procezoj ankaŭ povas plenumi.
Kelkfoje ĉi tiu paradigmo kondukas al interesaj artefaktoj. Longtempaj uzantoj de Linukso verŝajne memoras la frostigon de regula tekstredaktilo sur labortablo dum funkciado de rimedo-intensaj aplikaĵoj kiel ekzemple kompililo. Tio okazis ĉar ne-resurs-intensaj taskoj en labortablaj aplikoj konkuris kun resurs-intensaj taskoj, kiel ekzemple la kompililo. CFS opinias, ke tio estas maljusta, do ĝi periode haltigas la tekstredaktilon kaj lasas la procesoron prizorgi la taskojn de la kompililo. Ĉi tio estis korektita per mekanismo , sed multaj aliaj trajtoj de la distribuo de procesora tempo inter taskoj restis. Efektive, ĉi tio ne estas rakonto pri kiom malbona ĉio estas en CFS, sed provo atentigi pri tio, ke "justa" distribuo de procesora tempo ne estas la plej bagatela tasko.
Alia grava punkto en la planilo estas antaŭzorgo. Ĉi tio estas necesa por forĵeti la rikan procezon de la procesoro kaj lasi aliajn labori. La elĵetprocezo estas nomita kuntekstŝanĝo. En ĉi tiu kazo, la tuta kunteksto de la tasko estas konservita: la stato de la stako, registroj, ktp., post kiuj la procezo estas sendita por atendi, kaj alia prenas ĝian lokon. Ĉi tio estas multekosta operacio por la OS kaj malofte estas uzata, sed estas nenio esence malbona kun ĝi. Ofta kuntekstoŝanĝo povas indiki problemon en la OS, sed kutime ĝi estas kontinua kaj ne indikas ion aparte.
Tia longa historio necesas por klarigi unu fakton: ju pli da procesoraj rimedoj procezo provas konsumi en honesta Linuksa planilo, des pli rapide ĝi estos haltigita, por ke ankaŭ aliaj procezoj povu funkcii. Ĉu ĉi tio estas ĝusta aŭ ne, estas kompleksa demando, kiu povas esti solvita alimaniere sub malsamaj ŝarĝoj. En Vindozo, ĝis antaŭ nelonge, la planilo koncentriĝis pri prioritata prilaborado de labortablaj aplikoj, kiuj povus kaŭzi frostiĝon de fonaj procezoj. Sun Solaris havis kvin malsamajn klasojn de planistoj. Kiam ni lanĉis virtualigon, ni aldonis sesan, , ĉar la antaŭaj kvin ne funkciis adekvate kun Solaris Zones virtualigo. Mi rekomendas komenci detalan studon de tiu ĉi afero per libroj kiel aŭ .
2.4. Kiel kontroli ŝtelon?
Monitorado de ŝtelo en virtuala maŝino, kiel iu ajn alia procesora metriko, estas simpla: vi povas uzi ajnan procesoran metrikilon. La ĉefa afero estas, ke la virtuala maŝino estas en Linukso. Ial Vindozo ne provizas ĉi tiujn informojn al siaj uzantoj. 🙁
Eligo de la supra komando: detaloj de la procesoro-ŝarĝo, en la plej dekstra kolumno - ŝteli
La malfacilaĵo ŝprucas kiam oni provas akiri ĉi tiun informon de la hiperviziero. Vi povas provi antaŭdiri ŝtelon sur la gastiga maŝino, ekzemple, uzante la parametron Ŝarĝo-Mezumo (LA) - la averaĝa valoro de la nombro da procezoj atendantaj en la ekzekutvico. La metodo por kalkuli ĉi tiun parametron ne estas simpla, sed ĝenerale, se LA normaligita per la nombro da procesoraj fadenoj estas pli ol 1, tio indikas, ke la Linuksa servilo estas superŝarĝita per io.
Kion atendas ĉiuj ĉi tiuj procezoj? La evidenta respondo estas la procesoro. Sed la respondo ne estas tute ĝusta, ĉar foje la procesoro estas senpaga, sed LA malkreskas. Memoru . La sama povas okazi kun disko kaj aliaj enig/elig-aparatoj. Sed fakte, procezoj povas atendi la finon de iu ajn seruro, ĉu fizika, asociita kun I/O-aparato, aŭ logika, kiel mutekso. Ĉi tio ankaŭ inkluzivas ŝlosadon je la nivelo de aparataro (la sama respondo de la disko), aŭ logikon (la tielnomitaj ŝlosaj primitivuloj, kiu inkluzivas aron da entoj, mutex-adaptigaj kaj spinoj, semaforoj, kondiĉvariabloj, rw-seruroj, ipc-seruroj. ...).
Alia trajto de LA estas, ke ĝi estas konsiderata kiel operaciuma mezumo. Ekzemple, 100 procezoj konkuras por unu dosiero, kaj tiam LA=50. Tiel granda valoro ŝajnus indiki ke la operaciumo estas malbona. Sed por alia malrekte skribita kodo, tio povas esti normala stato, malgraŭ tio, ke nur ĝi estas malbona, kaj aliaj procezoj en la operaciumo ne suferas.
Pro ĉi tiu averaĝado (kaj en ne malpli ol minuto), determini ion ajn per la LA-indikilo ne estas la plej rekompenca tasko, kun tre necertaj rezultoj en specifaj kazoj. Se vi provos eltrovi ĝin, vi trovos, ke artikoloj en Vikipedio kaj aliaj disponeblaj rimedoj priskribas nur la plej simplajn kazojn, sen profunda klarigo de la procezo. Mi sendas al ĉiuj, kiuj interesiĝas, denove, - sekvu la subajn ligilojn. Kiu estas tro maldiligenta por paroli la anglan - .
3. Specialaj efektoj
Nun ni rigardu la ĉefajn kazojn de ŝtelo, kiujn ni renkontis. Mi diros al vi, kiel ili sekvas el ĉio supre kaj kiel ili rilatas al la indikiloj sur la hiperviziero.
Reciklado. La plej simpla kaj plej ofta: la hiperviziero estis reuzita. Efektive, estas multaj kurantaj virtualaj maŝinoj, alta procesora konsumo ene de ili, multe da konkurenco, LA-utiligo estas pli ol 1 (normaligita per procesoraj fadenoj). Ĉio ene de ĉiuj virtualaj maŝinoj malrapidiĝas. Ŝtelado transdonita de la hiperviziero ankaŭ kreskas, necesas redistribui la ŝarĝon aŭ malŝalti iun. Ĝenerale ĉio estas logika kaj komprenebla.
Paravirtualigo kontraŭ Unuopaj Okazoj. Ekzistas nur unu virtuala maŝino sur la hiperviziero; ĝi konsumas malgrandan parton de ĝi, sed produktas grandan I/O-ŝarĝon, ekzemple sur disko. Kaj de ie aperas en ĝi malgranda ŝtelo, ĝis 10% (kiel montras pluraj eksperimentoj).
La kazo estas interesa. Ŝteli aperas ĉi tie ĝuste pro blokado je la nivelo de paravirtualigitaj ŝoforoj. Interrompo estas kreita ene de la virtuala maŝino, prilaborita de la ŝoforo kaj sendita al la hiperviziero. Pro la interrompa uzado sur la hiperviziero, por la virtuala maŝino ĝi aspektas kiel sendita peto, ĝi estas preta por ekzekuto kaj atendas la procesoron, sed ĝi ne ricevas procesoran tempon. La virtuala knabino opinias, ke ĉi tiu fojo estis ŝtelita.
Ĉi tio okazas en la momento, kiam la bufro estas sendita, ĝi iras en la kernan spacon de la hiperviziero, kaj ni komencas atendi ĝin. Kvankam, el la vidpunkto de la virtuala maŝino, li tuj revenu. Sekve, laŭ la algoritmo de ŝtela kalkulado, ĉi tiu tempo estas konsiderata ŝtelita. Plej verŝajne, en ĉi tiu situacio povas ekzisti aliaj mekanismoj (ekzemple, prilaborado de iuj aliaj sys-vokoj), sed ili ne devus esti multe malsamaj.
Planilo kontraŭ tre ŝarĝitaj virtualaj maŝinoj. Kiam unu virtuala maŝino suferas ŝteli pli ol aliaj, tio estas pro la planilo. Ju pli procezo ŝarĝas la procesoron, des pli frue la planisto elĵetos ĝin por ke la aliaj ankaŭ povu funkcii. Se la virtuala maŝino konsumas malmulte, ĝi apenaŭ vidos ŝteli: ĝia procezo honeste sidis kaj atendis, ni devas doni al ĝi pli da tempo. Se virtuala maŝino produktas la maksimuman ŝarĝon sur ĉiuj siaj kernoj, ĝi ofte estas forĵetita el la procesoro kaj ili provas ne doni al ĝi multe da tempo.
Estas eĉ pli malbone kiam procezoj ene de la virtuala maŝino provas akiri pli da procesoro ĉar ili ne povas elteni datumtraktadon. Tiam la operaciumo sur la hiperviziero, pro honesta optimumigo, provizos malpli kaj malpli da procesora tempo. Ĉi tiu procezo okazas kiel lavango, kaj ŝtelas saltojn al la ĉielo, kvankam aliaj virtualaj maŝinoj povas apenaŭ rimarki ĝin. Kaj ju pli da kernoj, des pli malbona estas la tuŝita maŝino. Mallonge, tre ŝarĝitaj virtualaj maŝinoj kun multaj kernoj plej suferas.
Malalta LA, sed estas ŝtelo. Se LA estas proksimume 0,7 (tio estas, la hiperviziero ŝajnas esti subŝarĝita), sed ŝtelo estas observita ene de individuaj virtualaj maŝinoj:
- La opcio kun paravirtualigo jam priskribita supre. La virtuala maŝino povas ricevi metrikojn indikante ŝtelon, kvankam la hiperviziero estas bona. Laŭ la rezultoj de niaj eksperimentoj, ĉi tiu ŝtela opcio ne superas 10% kaj ne devus havi gravan efikon sur la agado de aplikoj ene de la virtuala maŝino.
- La LA-parametro estas malĝuste kalkulita. Pli precize, en ĉiu specifa momento ĝi estas ĝuste kalkulita, sed averaĝe pli ol unu minuto ĝi montriĝas subtaksita. Ekzemple, se unu virtuala maŝino je triono de la hiperviziero konsumas ĉiujn ĝiajn procesorojn dum ekzakte duonminuto, tiam LA je minuto sur la hiperviziero estos 0,15; kvar tiaj virtualaj maŝinoj laborantaj samtempe donos 0,6. Kaj la fakto, ke dum duona minuto sur ĉiu el ili estis sovaĝa ŝtelo je 25% laŭ la LA-indikilo, ne plu povas esti eltirita.
- Denove, pro la planisto, kiu decidis, ke iu manĝas tro multe kaj lasis tiun iun atendi. Intertempe mi ŝanĝos la kuntekston, pritraktos interrompojn kaj prizorgos aliajn gravajn sistemajn aferojn. Kiel rezulto, iuj virtualaj maŝinoj ne vidas problemojn, dum aliaj spertas gravan rendimentan degeneron.
4. Aliaj distordoj
Estas miliono pli da kialoj por distordi la justan revenon de procesora tempo sur virtuala maŝino. Ekzemple, hiperfadenado kaj NUMA enkondukas malfacilaĵojn en kalkuloj. Ili tute konfuzas la elekton de kerno por ekzekuti la procezon, ĉar la planisto uzas koeficientojn - pezojn, kiuj faras la kalkulon eĉ pli malfacila kiam ŝanĝas la kuntekston.
Estas distordoj pro teknologioj kiel turbo-akcelo aŭ, male, energiŝpara reĝimo, kiuj, kalkulante utiligon, povas artefarite pliigi aŭ malpliigi la frekvencon aŭ eĉ la tempotranĉon sur la servilo. Ebligi turbo-akcelon reduktas la rendimenton de unu procesora fadeno pro pliiĝo en la rendimento de alia. Nuntempe, informoj pri la nuna procesoro-frekvenco ne estas transdonitaj al la virtuala maŝino, kaj ĝi kredas, ke iu ŝtelas sian tempon (ekzemple, ĝi petis 2 GHz, sed ricevis duonon de tio).
Ĝenerale, povas esti multaj kialoj por distordo. Vi eble trovos ion alian en aparta sistemo. Estas pli bone komenci per la libroj al kiuj mi donis ligilojn supre, kaj retrovi statistikojn de la hiperviziero uzante utilecojn kiel perf, sysdig, systemtap, el kiuj .
5. Konkludoj
- Iom da ŝtelo povas okazi pro paravirtualigo, kaj ĝi povas esti konsiderata normala. Ili skribas en la Interreto, ke ĉi tiu valoro povas esti 5-10%. Dependas de la aplikoj ene de la virtuala maŝino kaj de la ŝarĝo, kiun ĝi metas sur siaj fizikaj aparatoj. Ĉi tie gravas atenti kiel aplikaĵoj sentas sin en virtualaj maŝinoj.
- La rilatumo de la ŝarĝo sur la hiperviziero kaj ŝtelo ene de la virtuala maŝino ne estas ĉiam klare interrilataj; ambaŭ taksoj de ŝtelo povas esti eraraj en specifaj situacioj sub malsamaj ŝarĝoj.
- La planisto havas malbonan sintenon al procezoj, kiuj multe demandas. Li provas doni malpli al tiuj, kiuj petas pli. Grandaj virtualaj maŝinoj estas malbonaj.
- Iom da ŝtelo povas esti la normo eĉ sen paravirtualigo (konsiderante la ŝarĝon ene de la virtuala maŝino, la karakterizaĵojn de la ŝarĝo de najbaroj, ŝarĝan distribuon tra fadenoj kaj aliajn faktorojn).
- Se vi volas eltrovi ŝteli en specifa sistemo, vi devas esplori diversajn eblojn, kolekti metrikojn, zorge analizi ilin kaj pensi kiel egale distribui la ŝarĝon. Devojiĝoj de iuj kazoj estas eblaj, kiuj devas esti konfirmitaj eksperimente aŭ rigarditaj en la kern-eraĉilo.
fonto: www.habr.com