Përshëndetje! Dua të flas me fjalë të thjeshta për mekanizmin e krijimit të steal brenda makinave virtuale dhe disa artefakte që kemi zbuluar gjatë hulumtimit, në të cilin unë pata për të hyrë si drejtor teknik i platformës së cloud-it . Platforma punon në KVM.
Koha e vjedhjes sĂ« CPU â Ă«shtĂ« koha gjatĂ« sĂ« cilĂ«s makina virtuale nuk merr burime procesori pĂ«r ekzekutimin e saj. Kjo kohĂ« llogaritet vetĂ«m nĂ« sistemet operative mysafir nĂ« mjediset e virtualizimit. Shkaku se ku shkojnĂ« kĂ«to burime tĂ« alokuara, ashtu si nĂ« jetĂ«, Ă«shtĂ« shumĂ« i paqartĂ«. Por ne vendosĂ«m tĂ« kuptojmĂ«, madje realizuam njĂ« sĂ«rĂ« eksperimentesh. Nuk Ă«shtĂ« se tani e dimĂ« gjithçka rreth steal, por do tĂ« ndajmĂ« disa gjĂ«ra interesante 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 kryen procese tĂ« tjera nĂ« sistemin operacional host, ndĂ«rsa ka vendosur procesin e makinĂ«s virtuale nĂ« pritje pĂ«r ekzekutim. Kjo do tĂ« thotĂ« se, steal konsiderohet si diferenca midis kohĂ«s kur procesi Ă«shtĂ« gati pĂ«r t'u ekzekutuar dhe kohĂ«s kur i Ă«shtĂ« caktuar koha e procesorit.
Metrika e steal-it merret nga bërthama e makinës virtuale nga hipervizori. Hipervizori nuk specifikon se cilat procese të tjera po kryen, thjesht thotë "deri sa jam i angazhuar, nuk mund t'i jap kohë atij". Në KVM mbështetje për llogaritjen e steal-it është shtuar në . Dy pika kryesore këtu janë:
- Makinë virtuale merr informacion për steal nga hipervizori. Kjo do të thotë se, nga këndvështrimi i humbjeve, për proceset që ndodhen brenda makinës virtuale, kjo është një matje e tërthortë që mund të jetë e ekspozuar ndaj distorsioneve të ndryshme.
- Hipervizori nuk ndan me makinĂ«n virtuale informacion mbi atĂ« qĂ« Ă«shtĂ« angazhuar me diçka tjetĂ«r â e rĂ«ndĂ«sishme Ă«shtĂ« qĂ« ai nuk i jep asaj kohĂ«. Siç Ă«shtĂ« e tillĂ«, makina virtuale nuk mund tĂ« identifikojĂ« distorsionet nĂ« treguesin e steal-it, qĂ« mund tĂ« vlerĂ«sohen sipas natyrĂ«s sĂ« proceseve konkurruese.
2. ĂfarĂ« ndikon te steal
2.1. Llogaritja e steal-it
Në thelb, steal konsiderohet në mënyrë të ngjashme me kohën e zakonshme të përdorimit të procesorit. Informacioni mbi mënyrën se si llogaritet përdorimi është i kufizuar. Mundësisht, sepse shumica mund ta konsiderojnë këtë çështje të dukshme. Por gjithashtu ka raste të ndryshme. Për t'u njohur me këtë proces, mund të lexoni : do të mësoni për shumë nuanca në llogaritjen e përdorimit dhe për situatat kur ky llogaritje mund të jetë e gabuar për shkak të arsyeve të mëposhtme:
- Teprica e temperaturës së procesorit, gjatë së cilës humbasin ciklet.
- Aktivizimi / çaktivizimi i turbo-boost, që çon në ndryshimin e frekuencës së procesorit.
- Ndryshimi i kohëzgjatjes së kuantës së kohës, që ndodh kur përdoren teknologjitë e kursimit të energjisë të procesorit, siç është SpeedStep.
- Problemi i llogaritjes së mesatares: një vlerësim i përdorimit prej 80 % brenda një minute mund të fshehë një shpërthim të përkohshëm në 100 %.
- Bllokimi ciklik (spin lock) shkakton që procesori të jetë i ngarkuar, por procesi i përdoruesit nuk sheh përparim në ekzekutimin e tij. Si rezultat, përdorimi i llogaritur i procesorit nga procesi do të jetë qind për qind, ndonëse fizikisht koha procesoriale nuk do të konsumohet nga procesi.
Nuk kam gjetur artikuj qĂ« pĂ«rshkruajnĂ« njĂ« llogaritje tĂ« tillĂ« pĂ«r steal (nĂ«se e dini â ndani nĂ« komentet). Por, sipas burimeve tĂ« origjinĂ«s, 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 (procesi i makinerisĂ« virtuale), i cili llogarit kohĂ«zgjatjen e qĂ«ndrimit tĂ« procesit KVM nĂ« gjendjen e pritjes pĂ«r kohĂ«n procesoriale. NumĂ«ruesi merr informacionin pĂ«r procesorin nga specifikimi i tij dhe kontrollon nĂ«se tĂ« gjitha tik-takĂ«t e tij janĂ« pĂ«rdorur nga procesi i makinerisĂ« virtuale. NĂ«se po, atĂ«herĂ« e llogarisim se procesori ka punuar vetĂ«m me procesin e makinerisĂ« virtuale. NĂ« tĂ« kundĂ«rt, ne informojmĂ« se procesori ishte angazhuar me diçka tjetĂ«r, ndodhi steal.
Procesi i numërimit të steal është i ekspozuar ndaj të njëjtave probleme si numërimi i zakonshëm i shfrytëzimit. Nuk mund të thuhet se këto probleme ndodhin shpesh, por duken të frikshme.
2.2. Llojet e virtualizimit në KVM
Në përgjithësi, ka tre lloje virtualizimi dhe të gjithë mbështeten nga KVM. Mënyra e shfaqjes së steal mund të varet nga lloji i virtualizimit.
Translacioni. Në këtë rast, funksionimi i sistemit operativ të makinës virtuale me pajisjet fizike të hipervizorit ndodh më pak kështu:
- Sistemi operativ mik të dërgon komandën e tij pajisjes mik.
- Drejtori i pajisjes mik pranon komandën, formon një kërkesë për BIOS-in e pajisjes dhe e dërgon atë në hipervizor.
- Procesi i hipervizorit kryen translacionin e komandës në një komandë për pajisjen fizike, duke e bërë atë, përfshirë, më të sigurt.
- Drejtori i pajisjes fizike pranon komandën e modifikuar dhe e dërgon atë në pajisjen fizike vetë.
- Rezultatet e ekzekutimit të komandave kthehen përsëri nëpër të njëjtin rrugë.
Avantazhi i virtualizimit është se 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, kryesisht, me performancën.
Virtualizimi harduerik. Në këtë rast, pajisja në nivelin harduerik kupton komandat nga sistemi operativ. Ky është mënyra më e shpejtë dhe më e mirë. Por, fatkeqësisht, mbështetet nga shumë pak pajisje fizike, hipervizorë dhe sisteme operative mysafire. Aktualisht, pajisjet kryesore që mbështesin virtualizimin harduerik janë procesorët.
Paravirtualizimi. Shkalla më e zakonshme e virtualizimit të pajisjeve mbi 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ë hipervizorëve (për shembull, me rrjetin ose grumbullin e disqeve) ose ndarjen e faqeve të memories ndodh duke përdorur API-në e hipervizorit, pa përkthimin e komandave të ulëta. Disavantazhi i këtij mënyre virtualizimi është nevoja për modifikimin e bërthamës së sistemit operativ mysafir, në mënyrë që ai të mund të ndërveprojë me hipervizorin përmes kësaj API-t. Por zakonisht kjo zgjidhet përmes instalimit të përshtatësve të veçantë në sistemin operativ mysafir. Në KVM, kjo API quhet .
Me virtualizimin, krahas transmisjonit, rruga për në pajisjen fizike shkurtohet ndjeshëm duke dërguar urdhra direkt nga makineria virtuale në procesin e hipervizorit në host. Kjo lejon përshpejtimin e ekzekutimit të të gjitha instruksioneve brenda makinerisë virtuale. Në KVM, për këtë përgjigjet API-ja virtio, e cila punon vetëm për disa pajisje të caktuara, si adapteri rrjetor ose disku. Pikërisht për këtë arsye, brenda makinave virtuale instalohen drvërë virtio.
Ankesa e këtij përshpejtimi është se jo të gjitha proceset që ekzekutohen brenda virtualkes mbeten brenda saj. Kjo krijon disa efekte speciale, që mund të çojnë në shfaqjen e steal. Një studim i detajuar i këtij çështjeje rekomandohet të fillohet me .
2.3. Rregullimi 'i drejtë'
Virtualka në hipervizor është, në fakt, një proces i zakonshëm, i cili i nënshtrohet ligjeve të planifikimit (distribuimit të burimeve midis proceseve) në bërthamën Linux, prandaj do ta shqyrtojmë atë më në detaje.
Në Linux përdoret një mekanizëm i njohur si CFS, Completely Fair Scheduler, i cili u bë menaxheri i parazgjedhur që nga bërthama 2.6.23. Për të kuptuar këtë algoritëm, mund të lexoni mbi Arkitekturën e Bërthamës së Linux-it ose kodin burimor. Thelbi i CFS qëndron në shpërndarjen e kohës së 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ë merr ai. Kjo garanton përfundimin "e ndershëm" të të gjithëve proceseve - që një proces të mos zërë gjithmonë të gjithë procesorët, dhe që proceset e tjera të mund të ekzekutohen gjithashtu.
Ndonjëherë, një paradigëm e tillë çon në artefakte interesante. Përdoruesit e vjetër të Linux-it me siguri e kujtojnë ngrirjen e redaktorit të zakonshëm të teksteve në desktop gjatë nisjes së aplikacioneve me kërkesa për burime, si kompajleri. Kjo ndodhte sepse detyrat që nuk kërkonin shumë burime konkurronin me detyrat që aktivisht konsumonin burime, si kompajleri. CFS mendon se kjo është e pabesueshme, prandaj periodikisht ndalon redaktorin e teksteve dhe i jep procesorit mundësinë të përpunojë detyrat e kompajlerit. Kjo u korrigjua me anë të mekanizmit , por ka shumë karakteristika të tjera të shpërndarjes së kohës së procesorit midis detyrave. Në fakt, kjo nuk është një tregim për sa keq është gjithçka në CFS, por një përpjekje për të tërhequr vëmendjen se shpërndarja "e ndershme" e kohës së procesorit nuk është një detyrë triviale.
Një moment tjetër i rëndësishëm në planifikues është preemption. Kjo është e nevojshme për të larguar një proces që ka ngrënë shumë burime nga procesori dhe për të lejuar që të tjerët të punojnë. Procesi i largimit quhet përkëdhelje e kontekstit, dhe në këtë rast ruhet i gjithë konteksti i detyrës: gjendja e stack-ut, regjistrat dhe të tjera, dhe pas kësaj procesi dërgohet të presë, ndërsa një tjetër merr vendin e tij. 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ë një problem në OS, por zakonisht ndodh vazhdimisht dhe nuk tregon ndonjë gjë të veçantë.
Kjo histori e gjatĂ« Ă«shtĂ« e nevojshme pĂ«r tĂ« shpjeguar njĂ« fakt: sa mĂ« shumĂ« burime tĂ« pĂ«rpiqet tĂ« konsumojĂ« procesi nĂ« njĂ« planifikues tĂ« ndershĂ«m Linux, aq mĂ« shpejt do tĂ« ndalohet, nĂ« mĂ«nyrĂ« qĂ« proceset e tjera tĂ« mund tĂ« punojnĂ« gjithashtu. NĂ«se Ă«shtĂ« e saktĂ« kjo apo jo â Ă«shtĂ« njĂ« pyetje e ndĂ«rlikuar qĂ« zgjidhet ndryshe nĂ« ngarkesa tĂ« ndryshme. NĂ« Windows, deri sĂ« fundmi, planifikuesi ishte orientuar drejt pĂ«rpunimit me prioritet tĂ« aplikacioneve desktop, çka shkaktonte ngadalĂ«simin e proceseve nĂ« sfond. NĂ« Sun Solaris kishte pesĂ« klasa tĂ« ndryshme planifikuesish. Kur u lançua virtualizimi, u shtua njĂ« e gjashtĂ«ta, , sepse pesĂ« tĂ« kaluarat punonin me virtualizimin e Zones Solaris nĂ« mĂ«nyrĂ« tĂ« papĂ«rshtatshme. Rekomandoj tĂ« filloni studimin e detajuar tĂ« kĂ«saj çështjeje me libra si ose .
2.4. Si të monitoroni steal?
TĂ« monitorosh steal brenda njĂ« maosin virtual si çdo metrikĂ« tjetĂ«r procesori Ă«shtĂ« e thjeshtĂ«: mund tĂ« pĂ«rdorĂ«sh çdo mjet pĂ«r tĂ« marrĂ« metrikat e procesorĂ«ve. E rĂ«ndĂ«sishme Ă«shtĂ« qĂ« virtualka tĂ« jetĂ« nĂ« Linux. Windows, tĂ« paktĂ«n pĂ«r njĂ« arsye, nuk jep informacion tĂ« tillĂ« pĂ«r pĂ«rdoruesit e saj. đ
PĂ«rmbledhja e komandĂ«s top: detajet mbi ngarkesĂ«n e procesorit, nĂ« kolonĂ«n e fundit tĂ« djathtĂ« â steal
VĂ«shtirĂ«sia ndodh kur pĂ«rpiqemi tĂ« marrim kĂ«to informacionet nga hipervizori. Mund tĂ« provoni tĂ« parashikoni steal nĂ« makinĂ« nikoqire, p.sh., nĂ« bazĂ« tĂ« parametrin Load Average (LA) â vlerĂ«s sĂ« mesatare tĂ« numrit tĂ« proceseve qĂ« presin nĂ« radhĂ« pĂ«r t'u ekzekutuar. Metoda 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 nĂ« diçka.
ĂfarĂ« po presin tĂ« gjitha kĂ«to procese? PĂ«rgjigja e qartĂ« â procesorin. Por pĂ«rgjigja nuk Ă«shtĂ« krejtĂ«sisht e saktĂ«, sepse ndonjĂ«herĂ« procesori Ă«shtĂ« i lirĂ«, por LA Ă«shtĂ« shumĂ« e lartĂ«. Kujtoni, . NjĂ«lloj mund tĂ« ndodhĂ« edhe me diskun dhe me pajisje tĂ« tjera hyrjeje/daljeje. Por nĂ« tĂ« vĂ«rtetĂ«, proceset mund tĂ« presin pĂ«r pĂ«rfundimin e çdo bllokimi, si bllokimi fizik, qĂ« lidhet me pajisjen e hyrjes/daljes, ashtu edhe bllokimi logjik, si mutex. KĂ«tu pĂ«rfshihen bllokimet nĂ« nivel hardueri (tĂ« njĂ«jtin pĂ«rgjigje nga disku), ose logjike (kĂ«shtu quhen primitive tĂ« bllokimit, qĂ« pĂ«rfshijnĂ« njĂ« mori entitetesh, mutex adaptiv dhe spin, semaforĂ«t, variablat e kushtit, rw locks, ipc locksâŠ).
Një tjetër veçori e LA është se ajo merret si mesatare mbi sistemin operativ. Për shembull, 100 procese konkurrojnë për një skedë, dhe atëherë LA=50. Ky vlerë i madh, duket se tregon se sistemi operativ ka probleme. Por për kodin e keq të shkruar, kjo mund të jetë një gjendje normale, përderisa vetëm ai është problematik, ndërsa proceset e tjera në sistemin operativ nuk vuajnë.
PĂ«r shkak tĂ« kĂ«tij mesatarizimi (duke filluar nga njĂ« minutĂ«), pĂ«rcaktimi i diçkaje me indikatorin LA â nuk Ă«shtĂ« njĂ« punĂ« e lehtĂ«, me rezultate tĂ« pasigurt nĂ« raste tĂ« caktuara. NĂ«se pĂ«rpiqeni tĂ« kuptoni, do tĂ« zbuloni se nĂ« artikujt e Wikipedia-s dhe burimeve tĂ« tjera tĂ« disponueshme pĂ«rmenden vetĂ«m rastet mĂ« tĂ« thjeshta, pa njĂ« shpjegim tĂ« thellĂ« tĂ« procesit. TĂ« gjithĂ« interesuarit e dĂ«rgoj, pĂ«rsĂ«ri,  â vazhdoni pĂ«rmes lidhjeve. 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 ne jemi përballur. Do të tregoj se si rrjedhin ato nga e gjitha që u tha më parë dhe si lidhen me treguesit në hipervizor.
Ritransferimi. E simplest dhe më e zakonshme: hipervizori po rishfrytëzohet. Në të vërtetë, ekzistojnë shumë instancat virtuale të nisura, me konsum të lartë të procesorit brenda tyre, konkurrencë të madhe, dhe u rishfrytëzohet më shumë se 1 (në normalizimin sipas thread-eve të procesorit). Brenda të gjitha instancave virtuale gjithçka ngadalësohet. Steal, e cila transmetohet nga hipervizori, gjithashtu rritet, duhet të rredisni ngarkesën ose të fikni ndonjë. Në përgjithësi, gjithçka është logjike dhe e qartë.
Paravirtualizimi kundër instancave të vetme. Në hipervizor ka vetëm një instancë virtuale, ajo konsumon një pjesë të vogël të tij, por jep një ngarkesë të madhe për hyrje/ dalje, për shembull në disk. Dhe ndonjëherë aty shfaqet një steal i vogël, deri në 10% (siç e tregojnë disa eksperimente të kryera).
Një rast interesant. Steal shfaqet këtu për shkak të bllokimeve në nivelin e drivereve të paravirualizuara. Brenda makinës virtuale krijohet një ndërprerje, e cila përpunohet nga drivari dhe shkon në hipervizor. Për shkak të përpunimit të ndërprerjes në hipervizor, kjo duket si një kërkesë e dërguar për makinën virtuale, e cila është gati për t'u ekzekutuar dhe pret procesorin, por nuk merr kohë procesori. Makinës virtuale i duket se kjo kohë është vjedhur.
Kjo ndodh në momentin e dërgimit të buferit, ai shkon në kernel space të hipervizorit, dhe ne fillojmë ta presim. Megjithatë, nga perspektiva e makinës virtuale, ai duhet të kthehet menjëherë. Prandaj, sipas algoritmit të llogaritjes së steal, kjo kohë konsiderohet si e vjedhur. Më shumë gjasa, në këtë situatë mund të ketë edhe mekanizma të tjerë (për shembull, përpunimi i ndonjë syscall tjetër), por ato nuk duhet të dallohet shumë.
Planifikuesi kundër makinave virtuale me ngarkesë të lartë. Kur një virtuale pëson më shumë steal se të tjerat, ky është një rezultat i planifikuesit. Sa më shumë të ngarkojë një procesori, aq më shpejt planifikuesi e nxjerr atë jashtë, në mënyrë që të tjerët të kenë mundësi të punojnë gjithashtu. Nëse virtualja konsumon pak, ajo nuk do ta shohë pothuajse aspak steal: procesi i saj ndenj mori pak dhe priste, duhet t'i jepet më shumë kohë. Nëse virtualja prodhon ngarkesë maksimale në të gjitha bërthamat e saj, ajo shpesh nxirret nga procesori dhe mundohet të mos i jepet shumë kohë.
Akoma më keq është kur proceset brenda virtuales përpiqen të fitojnë më shumë procesor, sepse nuk po i përballojnë të dhënat. Atëherë, sistemi operativ në hipervizor, përmes optimizimit të sinqertë, do t'i japë gjithnjë e më pak kohë të procesorit. Ky proces ndodh si një lavinë, dhe steal shumëzohet përsëri, megjithatë virtualet e tjera nuk e ndiejnë pothuajse fare. Sa më shumë bërthama, aq më keq është për makinën që është nën presion. Në përfundim, më së shumti vuajnë virtualet me ngarkesë të lartë me shumë bërthama.
LA e ulët, por ka steal. Nëse LA është rreth 0,7 (pra, hipervizori duket se është i ngarkuar pak), por brenda makinave virtuale të veçanta vërehet steal:
- Varianti i përmendur më sipër me paravirtualizimin. Makinat virtuale mund të marrin metrika që tregojnë për steal, ndonëse hipervizori është në gjendje të mirë. Nga rezultatet e eksperimenteve tona, ky lloj steal nuk kalon 10% dhe nuk duhet të ketë një ndikim të konsiderueshëm në performancën e aplikacioneve brenda makinës virtuale.
- Parametri LA mendohet gabim. Më saktë, në çdo moment të veçantë, ai llogaritet saktë, por duke u mesatarizuar për një minutë rezultati del i ulët. Për shembull, nëse një makinë virtuale konsumon të gjitha procesorët e hipervizorit për gjysmë minute, atëherë LA për minutën në hipervizor do të jetë 0,15; katër të tilla makina virtuale që punojnë njëherësh do të japin 0,6. Por ajo që për gjysmë minute çdo njëra prej tyre kishte steal maksimale prej 25% në treguesin LA, nuk mund të nxirret më.
- Sërish, për shkak të planifikuesit, që vendosi se dikush po konsumon shumë, e le të presë. Ndërkohë, unë do të ndërrojnë kontekstin, do të përpunoj ndërprerjet dhe do merrem me gjëra të tjera të rëndësishme për sistemin. Si rezultat, disa virtuale nuk shohin asnjë problem, ndërsa të tjerat përjetojnë një degradim serioz të performancës.
4. Shkakët e tjerë të deformimeve
Ka edhe njĂ« milion arsye pĂ«r deformimet e ndershme tĂ« kthimit tĂ« kohĂ«s procesorike nĂ« virtuale. PĂ«r shembull, kompleksitetet nĂ« llogaritje i sjellin hyperthreading dhe NUMA. KĂ«to pĂ«rfshihen nĂ« mĂ«nyrĂ« pĂ«rfundimtare nĂ« zgjedhjen e bĂ«rthamĂ«s pĂ«r ekzekutimin e proceseve, sepse planifikuesi pĂ«rdor coefficientĂ« â pesha qĂ«, gjatĂ« ndĂ«rrimit tĂ« konteksteve, e bĂ«jnĂ« llogaritjen akoma mĂ« tĂ« komplikuar.
Mund të ketë deformime për shkak të teknologjive si turbo-luftimi ose, anasjelltas, moda e ruajtjes së energjisë, të cilat gjatë llogaritjes së përdorimit mund të rrisin ose ulin në mënyrë artificiale frekuencën ose madje kohën kuantike në server. Aktivizimi i turbo-luftimit zvogëlon performancën e një nyje procesori për shkak të rritjes së performancës së një tjetre. Në këtë moment, informacioni mbi frekuencën aktuale të procesorit nuk i kalon makinerisë virtuale dhe ajo mendon se koha e saj po vidhet nga dikush (p.sh., ajo kërkoi 2 GHz, por mori gjysmën).
PĂ«rgjithĂ«sisht, mund tĂ« ketĂ« shumĂ« shkaqe pĂ«r deformime. NĂ« njĂ« sistem tĂ« caktuar mund tĂ« zbuloni diçka tjetĂ«r. ĂshtĂ« mĂ« mirĂ« tĂ« filloni me librat, pĂ«r tĂ« cilĂ«t kam dhĂ«nĂ« lidhjet mĂ« sipĂ«r, dhe tĂ« merrni statistikĂ«n nga hipervizori me mjete si perf, sysdig, systemtap, tĂ« cilat ka .
5. PĂ«rfundimet
- Një sasi e caktuar steal mund të ndodhë për shkak të paravirtualizimit dhe mund të konsiderohet normale. Në internet shkruhet se ky vlerë mund të arrijë 5-10 %. Varet nga aplikacionet brenda virtuales dhe nga ngarkesa që ajo jep në pajisjet fizike. Këtu është e rëndësishme të vëmendni se si ndihen aplikacionet brenda virtualeve.
- Raporti i ngarkesës në hipervizor dhe steal brenda virtuales nuk janë gjithmonë të lidhura ngushtë; të dy vlerat e steal mund të jenë të gabuara në situata specifike me ngarkesa të ndryshme.
- Sheduleri nuk i pëlqen proceset që kërkojnë shumë. Ai përpiqet t'i japë më pak atyre që kërkojnë më shumë. Virtualet e mëdha janë një problem.
- Një steal i vogël mund të jetë normal edhe pa paravirtualizim (duke marrë parasysh ngarkesën brenda virtuales, karakteristikat e ngarkesës së fqinjëve, shpërndarjen e ngarkesës sipas tread-ave dhe faktorë të tjerë).
- Nëse dëshironi të kuptoni steal në një sistem të caktuar, duhet të hulumtoni variante të ndryshme, të mbledhni metrika, t'i analizoni ato me kujdes dhe të mendoni se si të shpërndani ngarkesën në mënyrë të barabartë. Ka mundësi për devijime nga çdo rast, të cilat duhet të konfirmohen eksperimental ose të shihni në debagerin e bërthamës.
Burimi: habr.com
