Përshëndetje! Dua të flas në një mënyrë të thjeshtë për mekanikën e shfaqjes së steal brenda makinave virtuale dhe për disa artefakte të padukshme, që arritëm të zbulojmë gjatë kërkimit tonë, në të cilin u përqendrua ndihmësi im si drejtori teknik i platformës në re. . Platforma funksionon në KVM.
Koha e steal CPU është koha gjatë së cilës një makinë virtuale nuk merr burime procesori për ekzekutimin e saj. Kjo kohë konsiderohet vetëm në sistemet operativë mikpritës në mjedise virtualizimi. Shkaqet se ku shkojnë këto burime të rezervuara, ashtu si në jetë, janë mjaft të paqartë. Por vendosëm të kuptojmë, madje bëmë një seri eksperimentesh. Nuk është se tani e dimë gjithçka për steal, por disa gjëra interesante do t'ju tregojmë tani.
1. ĂfarĂ« Ă«shtĂ« steal
Pra, steal është një metrikë që tregon mungesën e kohës së procesorit për proceset brenda makinës virtuale. Siç përshkruhet , steal është koha gjatë së cilës hipervizori ekzekuton procese të tjera në sistemin operativ mikpritës, ndërsa ka vendosur procesin e makinës virtuale në radhë për ekzekutim. Kështu, steal llogaritet si diferenca midis kohës kur procesi është i gatshëm për t'u ekzekutuar dhe kohës kur procesit i janë rezervuar burimet e procesorit.
Metrika steal e merr bërthamën e makinës virtuale nga hipervizori. Ndërkohë, hipervizori nuk saktëson se cilat procese të tjera po ekzekuton; thjesht "kur jam i zënë, nuk mund të të kushtoj kohë". Në KVM mbështetje për llogaritjen e steal është e shtuar në Ka dy pika kyçe këtu:
- Makina virtuale merr informacion për steal nga hipervizori. Kështu që, nga pikëpamja e humbjeve, për proceset në vetë makinë virtuale, kjo është një masë indirekte, që mund të jetë subjekt i deformimeve të ndryshme.
- Hipervizori nuk ndan me makinĂ«n virtuale informacionin se me çfarĂ« tjetĂ«r Ă«shtĂ« i zĂ«nĂ« â e rĂ«ndĂ«sishme Ă«shtĂ« qĂ« ai nuk i kushton kohĂ« asaj. PĂ«r kĂ«tĂ« arsye, vetĂ« makina virtuale nuk mund tĂ« zbulojĂ« deformimet nĂ« treguesin steal, qĂ« mund tĂ« vlerĂ«soheshin nga karakteri i proceseve konkuruese.
2. ĂfarĂ« ndikon nĂ« steal
2.1. Llogaritja e steal
Në thelb, steal llogaritet përafërsisht ashtu si koha normale e utilizimit të procesorit. Informacioni mbi si llogaritet utilizimi nuk është i madh. Ndoshta sepse shumica e konsideron këtë çështje të qartë. Por këtu gjithashtu ka kapriçio. Për t'u njohur me këtë proces, mund të lexoni : do të mësoni për një sasi të madhe nuancash gjatë llogaritjes së përdorimit dhe për situatat kur ky llogaritje do të ishte e gabuar për arsyet e mëposhtme:
- Teprica e procesorit, gjatë së cilës humbasin ciklet.
- Aktivizimi / çaktivizimi i turbo-boost-it, i cili ndryshon frekuencën e procesorit.
- Ndryshimi i kohëzgjatjes së kvantit të kohës, që ndodh gjatë përdorimit të teknologjive për kursimin e energjisë të procesorit, si SpeedStep.
- Problemi i llogaritjes mesatare: vlerësimi i përdorimit në një minute në nivelin e 80% mund të fshijë një shpërthim të përkohshëm në 100%.
- Bllokimi ciklik (spin lock) çon në një përdorim të procesorit, por procesi i përdoruesit nuk sheh përparim në ekzekutimin e tij. Si rezultat, llogaritja e përdorimit të procesorit nga procesi do të jetë njëqind përqind, ndonëse fizikisht koha e procesorit nuk do të përdoret nga procesi.
Nuk kam gjetur artikuj që përshkruajnë një llogaritje të tillë për steal (nëse dini, ju lutem ndani në komentet). Megjithatë, sipas burimeve, mekanizmi i llogaritjes është i njëjtë si për përdorimin. Thjesht në bërthamë shtohet një numërues tjetër, për procesin KVM (procesin virtual të makinës), i cili llogarit kohëzgjatjen e qëndrimit të procesit KVM në gjendjen e pritjes së kohës së procesorit. Numëruesi merr informacionin për procesorin nga specifikimi i tij dhe shikon nëse të gjitha tik-takët e tij janë përdorur nga procesi i virtualizimit. Nëse po, atëherë llogarisim se procesori ishte angazhuar vetëm me procesin e makinës virtuale. Në të kundërt, ne informojmë se procesori ishte angazhuar me diçka tjetër, u shfaq steal.
Procesi i llogaritjes së steal është i ekspozuar ndaj të njëjtave probleme si llogaritja e zakonshme e përdorimit. Nuk mund të thuhet se këto probleme ndodhin shpesh, por duken demoralizuese.
2.2. Llojet e virtualizimit në KVM
Në rregull, ka tre lloje virtualizimi, dhe të gjitha mbSupported by KVM. Nga lloji i virtualizimit mund të varet mekanizmi i shfaqjes së steal.
Translacioni. Në këtë rast, funksionimi i sistemit operativ të makinës virtuale me pajisjet fizike të hipervizorit ndodh përafërsisht kështu:
- Sistemi operativ mikpritës i dërgon pajisjes së tij mikpritëse një urdhër.
- Drejtuesi i pajisjes mikpritëse merr urdhrin, formon një kërkesë për BIOS-in e pajisjes dhe e dërgon atë në hipervizor.
- Procesi i hipervizorit bën translacionin e komandës në komandën për pajisjen fizike, çka e bën atë, përfshirë, më të sigurt.
- Drejtuesi i pajisjes fizike pranon komandën e modifikuar dhe e dërgon atë në pajisjen fizike.
- Rezultatet e ekzekutimit të komandave kthehen nëpër të njëjtin rrugë.
Avantazhi i translacionit është se ai lejon emulimin e çdo pajisjeje dhe nuk kërkon përgatitje të veçantë të bërthamës së sistemit operativ. Por për këtë, duhet të paguani, sidomos për sa i përket shpejtësisë.
Virtualizimi harduerik. Në këtë rast, pajisja në nivelin harduerik kupton komandat nga sistemi operativ. Kjo është mënyra më e shpejtë dhe më e mirë. Por, fatkeqësisht, ajo nuk mbështetet nga të gjitha pajisjet fizike, hipervizorët dhe sistemet operuese mysafir. Aktualisht, pajisjet kryesore që mbështesin virtualizimin harduerik janë procesorët.
Paravirtualizimi (paravirtualization). Varianti më i zakonshëm i virtualizimit të pajisjeve në KVM dhe gjithashtu mënyra më e zakonshme e virtualizimit për sistemet operative mysafir. Karakteristika e saj është se punimi me disa nën-sisteme të hipervizorit (për shembull, me gruan e rrjetit ose gruan e diskut) ose ndarja e faqeve të memories kryhet duke përdorur API-në e hipervizorit, pa translacionin e komandave të nivelit të ulët. Disavantazhi i këtij mënyre të virtualizimit është nevoja për modifikimin e bërthamës së sistemit operativ mysafir, në mënyrë që ai të mund të interagojë me hipervizorin përmes kësaj API. Por zakonisht kjo zgjidhet me anë të instalimit të drejtuesve të veçantë në sistemin operativ mysafir. Në KVM kjo API quhet .
Me paravirtualizimin, në krahasim me translacionin, rruga deri te pajisja fizike shkurtëzohet ndjeshëm përmes dërgimit të komandave direkt nga makina virtuale në procesin e hipervizorit në host. Kjo lejon të përshpejtohet ekzekutimi i të gjitha instruksioneve brenda makinës virtuale. Në KVM, kjo është në përgjegjësi të API-së virtio, e cila funksionon vetëm për pajisje të caktuara, siç janë adaptori i rrjetit ose disku. Pikërisht për këtë arsye në makinat virtuale instalohet drejtuesit virtio.
Ankesa e këtij përshpejtimi është se jo të gjithë proceset që përfundohen brenda virtualkes mbeten brenda saj. Kjo krijon disa efekte speciale që mund të sjellin shfaqjen në steal. Rekomandoj të filloni një studim të detajuar të kësaj çështjeje nga .
2.3. Planifikimi "i drejtë"
Virtualka mbi hipervizorin është, në fakt, një proces normal që i nënshtrohet ligjeve të planifikimit (distribucioni i burimeve midis proceseve) në bërthamën Linux, prandaj do ta shqyrtojmë atë në detaje.
Në Linux përdoret një sistem i quajtur CFS, Completely Fair Scheduler, i cili nga bërthama 2.6.23 është bërë menaxheri i paracaktuar. Për të kuptuar këtë algoritëm, mund të lexoni Arkitekturën e Bërthamës Linux ose kodin burimor. Qëllimi i CFS është të ndajë kohën e procesorit midis proceseve në varësi të kohës së tyre të ekzekutimit. Sa më shumë kohë procesori të kërkojë një proces, aq më pak kohë do të marrë. Kjo garanton një ekzekutim "të ndershëm" të të gjithë proceseve - në mënyrë që një proces të mos zërë gjithmonë të gjithë procesorët dhe proceset e tjera të kenë mundësi të ekzekutohen.
Ndonjëherë, kjo paradigmë sjell artefakte interesante. Përdoruesit e gjatë të Linux sigurisht që do të kujtojnë ngrirjen e redaktorit të zakonshëm të tekstit në desktop gjatë aktivizimit të aplikacioneve që konsumojnë shumë burime, si kompilatori. Kjo ndodhte sepse detyrat e pakonsumatore të aplikacioneve desktop konkurronin me detyrat aktive që konsumonin burime, si kompilatori. CFS mendon se kjo nuk është e drejtë, prandaj ndalon periodikisht redaktorin e tekstit dhe i jep procesorit mundësinë të përpunojë detyrat e kompilatorit. Kjo u rregullua me mekanizmin , por shumë karakteristika të tjera të shpërndarjes së kohës së procesorit midis detyrave mbeten. Në thelb, kjo nuk është një histori se si gjithçka është keq në CFS, por një përpjekje për t'u kujtuar se shpërndarja "e ndershme" e kohës së procesorit nuk është një detyrë triviale.
Një tjetër çështje e rëndësishme në planifikues është preemption. Kjo është e nevojshme për të larguar një proces që ka konsumuar shumë resurse nga procesori dhe për t'i dhënë mundësi të tjerëve të punojnë. Procesi i largimit quhet kalimi i kontekstit, ose context switching i procesorit. Në këtë rast, ruhet i gjithë konteksti i detyrës: gjendja e stack-ut, regjistrat dhe të tjera, pas së cilës procesi dërgohet për të pritur, ndërsa në vendin e tij futet një tjetër. Kjo është një operacion i kushtueshëm për OS-në dhe përdoret rrallë, por në thelb nuk ka asgjë të keqe në të. Ndryshimi i shpeshtë i kontekstit mund të tregojë për një problem në OS, por zakonisht ndodh vazhdimisht dhe nuk tregon ndonjë gjë të veçantë.
Ky tregim i gjatĂ« Ă«shtĂ« i nevojshĂ«m pĂ«r tĂ« shpjeguar njĂ« fakt: sa mĂ« shumĂ« resurse tĂ« procesorit pĂ«rpiqet tĂ« konsumojĂ« njĂ« proces nĂ« njĂ« planifikues tĂ« ndershĂ«m Linux, aq mĂ« shpejt do tĂ« ndalet, qĂ« tĂ« mund tĂ« punojnĂ« edhe proceset e tjera. NĂ«se Ă«shtĂ« e drejtĂ« apo jo â Ă«shtĂ« njĂ« pyetje e komplikuar, e cila zgjidhet ndryshe me ngarkesa tĂ« ndryshme. NĂ« Windows deri kohĂ«t e fundit, planifikuesi ishte i orientuar pĂ«r pĂ«rpunimin me prioritet tĂ« aplikacioneve desktop, gjĂ« qĂ« mund tĂ« sillte ngecje tĂ« proceseve nĂ« sfond. NĂ« Sun Solaris kishte pesĂ« klasa tĂ« ndryshme planifikuesish. Kur u nisi virtualizimi, u shtua klasa e gjashtĂ«, , sepse pesĂ« tĂ« mĂ«parshmet nuk punonin adekuat me virtualizimin e Solaris Zones. NjĂ« studim i detajuar i kĂ«tij problemi rekomandohet tĂ« fillohet me libra si ose .
2.4. Si të monitoroni steal?
TĂ« monitoroni steal brenda njĂ« makine virtuale, si dhe çdo metrikĂ« tjetĂ«r tĂ« procesorit, Ă«shtĂ« e thjeshtĂ«: mund tĂ« pĂ«rdorni çdo mjet pĂ«r tĂ« marrĂ« metrikat e procesorit. GjĂ«ja kryesore Ă«shtĂ« qĂ« virtualka tĂ« jetĂ« nĂ« Linux. Windows pĂ«r njĂ« arsye tĂ« panjohur nuk ofron njĂ« informacion tĂ« tillĂ« pĂ«r pĂ«rdoruesit e saj. đ
Dalja e komandĂ«s top: detajimi i ngarkesĂ«s sĂ« procesorit, nĂ« kolumnĂ«n mĂ« tĂ« djathtĂ« â steal
VĂ«shtirĂ«sitĂ« paraqiten kur pĂ«rpiqeni tĂ« merrni kĂ«tĂ« informacion nga hipervizori. Mund tĂ« provoni tĂ« parashikoni steal nĂ« makinĂ«n host, pĂ«r shembull, pĂ«rmes parametrave Load Average (LA) â vlera mesatare e numrit tĂ« proceseve qĂ« presin nĂ« radhĂ« pĂ«r tĂ« ekzekutuar. Metodologjia e llogaritjes sĂ« kĂ«tij parametri nuk Ă«shtĂ« e thjeshtĂ«, por nĂ« pĂ«rgjithĂ«si, nĂ«se LA e normalizuar sipas numrit tĂ« fijeve tĂ« procesorit Ă«shtĂ« mĂ« e madhe se 1, kjo tregon se serveri me Linux Ă«shtĂ« ngarkuar me diçka.
ĂfarĂ« presin tĂ« gjithĂ« kĂ«ta procese? PĂ«rgjigjja e qartĂ« Ă«shtĂ« processori. Por pĂ«rgjigjja nuk Ă«shtĂ« plotĂ«sisht e saktĂ«, sepse ndonjĂ«herĂ« procesori Ă«shtĂ« i lirĂ«, ndĂ«rsa LA gĂ«rryehet. Kujtoni, . MĂ«nyra se si ndodh me diskun dhe pajisjet e tjera tĂ« hyrjes/daljes. NĂ« tĂ« vĂ«rtetĂ«, proceset mund tĂ« presin pĂ«rfundimin e çdo bllokimi, si fizik, i lidhur me pajisjen e hyrjes/daljes, ashtu edhe logjik, si mutexi. KĂ«tu pĂ«rfshihen bllokimet nĂ« nivel harduari (pĂ«rgjigja e njĂ«jtĂ« nga disku) ose logjike (tĂ« ashtuquajturit primitive tĂ« bllokimit, ku pĂ«rfshihen shumĂ« entitete, mutex adaptiv dhe spin, semaforĂ«, variabla kushtesh, rw locks, ipc locksâŠ).
Një veçori tjetër e LA është se llogaritet si një vlerë mesatare për sistemin operativ. Për shembull, 100 procese konkurrojnë për një skedar, dhe atëherë LA=50. Një vlerë kaq e madhe, duket se tregon se operacioni është në gjendje të keqe. Por për një kod të keq të shkruar, kjo mund të jetë një gjendje normale, me faktin se e keqja i përket vetëm atij, ndërsa proceset e tjera në operacion nuk vuajnë.
PĂ«r shkak tĂ« kĂ«tij mesatarizimi (nĂ« tĂ« vĂ«rtetĂ«, jo mĂ« pak se njĂ« minutĂ«), pĂ«rcaktimi i ndonjĂ« gjĂ«je nĂ« bazĂ« tĂ« treguesit LA â nuk Ă«shtĂ« njĂ« aktivitet i frytshĂ«m, me rezultate shumĂ« tĂ« pasigurta nĂ« raste tĂ« veçanta. Po tĂ« pĂ«rpiqeni tĂ« zbuloni, do tĂ« zbuloni se nĂ« artikujt nĂ« Wikipedia dhe burimet e tjera tĂ« disponueshme, pĂ«rshkruhen vetĂ«m rastet mĂ« tĂ« thjeshta, pa shpjegim tĂ« thellĂ« tĂ« procesit. TĂ« gjithĂ« tĂ« interesuarit dĂ«rgoj, pĂ«rsĂ«ri,  â mĂ« pas pĂ«rmes lidhjeve. PĂ«r ata qĂ« nuk kanĂ« dĂ«shirĂ« nĂ« anglisht â .
3. Efektet speciale
Tani do të ndalemi te rastet kryesore të shfaqjes së steal, me të cilat kemi përballur. Do të tregoj se si derivojnë nga gjithçka e thënë më parë dhe si lidhen me treguesit në hipervizor.
Rishfrytëzimi. Më e thjeshtë dhe më e zakonshme: hipervizori është i rishfrytëzuar. Në të vërtetë, shumë makina virtuale janë të nisura, konsumi i procesorit brenda tyre është i lartë, konkurenca është e madhe, shfrytëzimi sipas LA është më shumë se 1 (në normalizim sipas thithjeve të procesorëve). Brenda të gjitha makinerive virtuale gjithçka është duke u ngadalësuar. Steal, e cila kalon nga hipervizori, gjithashtu rritet, duhet të shpërndahen ngarkesat ose të mbyllet dikush. Në përgjithësi, gjithçka është logjike dhe e qartë.
Paravirtualizimi kundrejt instancave të vetme. Në hipervizor ka vetëm një virtuale, ajo konsumon një pjesë të vogël të tij, por jep një ngarkesë të madhe në hyrje/dalje, për shembull për diskun. Dhe nga diku në të shfaqet një steal i vogël, deri në 10% (ashtu siç tregojnë disa eksperimente të kryera).
Një rast interesant. Steal këtu shfaqet pikërisht për shkak të bllokimeve në nivelin e drejtorëve të para-virtualizuar. Brenda virtuales krijohet një ndërprerje, e cila përpunohet nga drejtori dhe shkon në hipervizor. Për shkak të përpunimit të ndërprerjes në hipervizor, për virtualen duket si një kërkesë e dërguar, ajo është e gatshme për ekzekutim dhe po pret procesorin, por kohën e procesorit nuk e marrin. Virtualja mendon se ky kohë është vjedhur.
Kjo ndodh në momentin e dërgimit të tamponit, ai shkon në hapësirën e kernel-it të hipervizorit, dhe ne fillojmë ta presim. Megjithatë, nga këndvështrimi i virtuales, ai duhet të kthehet menjëherë. Prandaj, sipas algoritmit të llogaritjes së steal, ky kohë konsiderohet e vjedhur. Probabilisht, në këtë situatë mund të ketë edhe mekanizma të tjerë (për shembull, përpunimi i ndonjë sys calls), por ata nuk duhet të ndahen shumë.
Planifikuesi kundĂ«r virtualeve me ngarkesĂ« tĂ« lartĂ«. Kur njĂ« virtuale vuan mĂ« shumĂ« nga steal sesa tĂ« tjerat, kjo lidhet pikĂ«risht me planifikuesin. Sa mĂ« shumĂ« ngarkesĂ« procesorike tĂ« ketĂ« procesi, aq mĂ« parĂ« planifikuesi do ta largohet, nĂ« mĂ«nyrĂ« qĂ« tĂ« tjerĂ«t tĂ« mund tĂ« punojnĂ« gjithashtu. NĂ«se virtualja konsumon pak, ajo gati nuk do tĂ« shohĂ« steal: procesi i saj ka pritur dhe duhet t'i jepet mĂ« shumĂ« kohĂ«. NĂ«se virtualja prodhon ngarkesĂ«n maksimale nĂ« tĂ« gjitha bĂ«rthamĂ«n e saj, ajo shpesh largohet nga procesori dhe pĂ«rpiqen tâi jepen mĂ« pak kohĂ«.
Akoma më keq, kur proceset brenda virtuales përpiqen të fitojnë më shumë procesorë, sepse nuk përballen me përpunimin e të dhënave. Atëherë sistemi operativ në hipervizor, me optimizimin e tij të ndershëm, do të japë gjithnjë e më pak kohë procesori. Ky proces ndodh në mënyrë shpërthyese, dhe steal rritet në qiell, megjithatë virtualet e tjera mund ta kenë vështirë ta vërejnë. Dhe sa më shumë bërthama, aq më keq për makinën që ka marrë goditjen. Në përmbledhje, më së shumti vuajnë virtualet me ngarkesë të lartë dhe me shumë bërthama.
LA i ulët, por ka steal. Nëse LA është rreth 0.7 (domethënë, hipervizori duket se është pak i ngarkuar), por brenda disa virtualeve vërehet steal:
- Versioni e përmendur më lart me para-virtualizim. Virtualka mund të merr metrika që tregojnë për steal, megjithëse hipervizori është në rregull. Sipas rezultateve të eksperimenteve tona, një steal i tillë nuk kalon 10% dhe nuk duhet të ketë ndikim të rëndësishëm mbi performancën e aplikacioneve brenda virtualkës.
- Emri LA konsiderohet gabimisht. Në mënyrë të saktë, në çdo moment të veçantë ai matet mirë, por kur merret mesatarja për një minutë, rezultati është më i ulët. Për shembull, nëse një virtualka në një të tretën e hipervizorit konsumon të gjitha procesorët e saj për gjysmë minute, LA për minutën në hipervizor do të jetë 0,15; katër të tilla virtualka që punojnë njëkohësisht do të japin 0,6. Ndërkohë, ajo që për gjysmë minute secila prej tyre kishte steal të egër mbi 25% në treguesin LA, tashmë nuk mund të shpëtohet.
- Përsëri, për shkak të shedulerit, i cili vendosi se dikush po konsumon shumë, dhe le të presë ai dikush. Ndërkohë që unë do të kaloj kontekstin, do të përpunoj ndërprerjet dhe do të merrem me gjëra të tjera të rëndësishme të sistemit. Si rezultat, disa virtualka nuk shohin asnjë problem, ndërsa të tjerët përjetojnë një degradim serioz të performancës.
4. Izolime të tjera
Ka ende një milion arsye për izolime në kthimin e ndershëm të kohës së procesorit në virtualka. Për shembull, komplikimet në llogaritje sjellin hipertredhjen dhe NUMA. Ato e bëjnë zgjedhjen e bërthamave për ekzekutimin e procesit përfundimisht më të komplikuar, sepse sheduleri përdor koeficientët - pesha, të cilat e bëjnë llogaritjen edhe më të komplikuar gjatë kalimit të kontekstit.
Mund të ndodhin izolime për shkak të teknologjive si turbo boost ose, përkundrazi, mënyra e kursimit të energjisë, të cilat gjatë llogaritjes së përdorimit mund të rrisin artificialisht ose të ulin frekuencën ose madje qindarën e kohës në server. Aktivizimi i turbo boost redukton performancën e një thread-i të procesorit për shkak të rritjes së performancës së një tjetri. Në këtë moment, informacioni mbi frekuencën aktuale të procesorit nuk i dërgohet virtualkës dhe ajo mendon se koha e saj po vidhet nga dikush (për shembull, ajo kërkoi 2 GHz, por mori gjysmë më pak).
NĂ« pĂ«rgjithĂ«si, mund tĂ« ketĂ« shumĂ« arsye pĂ«r izolime. NĂ« njĂ« sistem tĂ« caktuar mund tĂ« zbuloni diçka tjetĂ«r. ĂshtĂ« mĂ« mirĂ« tĂ« filloni me librat mbi tĂ« cilat kam dhĂ«nĂ« lidhje mĂ« lart dhe tĂ« merrni statistika nga hipervizori me mjete si perf, sysdig, systemtap, tĂ« cilat janĂ« .
5. PĂ«rfundime
- NjĂ« sasi e caktuar steal mund tĂ« ndodhĂ« pĂ«r shkak tĂ« paravirtualizimit dhe mund tĂ« konsiderohet normale. NĂ« internet shkruhet se kjo madhĂ«si mund tĂ« arrijĂ« 5-10%. Varet nga aplikacionet brenda virtualizimit dhe nga ngarkesa qĂ« ato i japin pajisjeve fizike. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kushtohet vĂ«mendje se si ndihen aplikacionet brenda virtualizimeve.
- Raporti i ngarkesës në hypervisor dhe steal brenda virtualizimit nuk janë gjithmonë në një marrëdhënie të qartë, të dy vlerësimet e steal mund të jenë të gabuara në situata të caktuara me ngarkesa të ndryshme.
- Planifikuesi nuk ka mirëpritje për proceset që kërkojnë shumë. Ai përpiqet të japë më pak atyre që kërkojnë më shumë. Virtualizimet e mëdha janë të këqija.
- Një steal i vogël mund të jetë normale edhe pa paravirtualizim (duke marrë parasysh ngarkesën brenda virtualizimit, veçoritë e ngarkesës nga fqinjët, shpërndarjen e ngarkesës në tread dhe faktorë të tjerë).
- Nëse dëshironi të zbuloni steal në një sistem të caktuar, duhet të hulumtoni variante të ndryshme, të grumbulloni metrika, t'i analizoni me kujdes dhe të mendoni se si të shpërndani në mënyrë të barabartë ngarkesën. Nga çdo rast mund të ketë deviacione që duhet të konfirmohen eksperimentalisht ose të shqyrtohen në debuguerin e bërthamës.
Burimi: habr.com
