ProHoster > Blogs > Administrācija > Nozagt: kurŔ zog procesora laiku no virtuālajām maŔīnām

Nozagt: kurŔ zog procesora laiku no virtuālajām maŔīnām

Nozagt: kurŔ zog procesora laiku no virtuālajām maŔīnām

Sveiki! Es vēlos jums vienkārŔā izteiksmē pastāstÄ«t par zagÅ”anas mehāniku virtuālajās maŔīnās un par dažiem acÄ«mredzamiem artefaktiem, kurus mums izdevās noskaidrot tās izpētes laikā un kuros man bija jāiedziļinās kā mākoņa platformas tehniskajam direktoram. Mail.ru mākoņa risinājumi. Platforma darbojas KVM.

CPU nozagÅ”anas laiks ir laiks, kurā virtuālā maŔīna nesaņem procesora resursus tās izpildei. Å is laiks tiek skaitÄ«ts tikai viesu operētājsistēmās virtualizācijas vidēs. Iemesli, kādēļ Å”ie visvairāk pieŔķirtie resursi paliek, tāpat kā dzÄ«vē, ir ļoti neskaidri. Bet mēs nolēmām to izdomāt un pat veicām vairākus eksperimentus. Nav tā, ka mēs tagad zinām visu par zagÅ”anu, bet tagad mēs jums pastāstÄ«sim kaut ko interesantu.

1. Kas ir zagt

Tātad zagÅ”ana ir metrika, kas norāda uz procesora laika trÅ«kumu procesiem virtuālajā maŔīnā. Kā aprakstÄ«ts KVM kodola ielāpāMaskÄ“Å”anās ir laiks, kurā hipervizors resursdatora operētājsistēmā izpilda citus procesus, lai gan tas ir ievietojis virtuālās maŔīnas procesu izpildei. Tas nozÄ«mē, ka nozagÅ”ana tiek aprēķināta kā starpÄ«ba starp laiku, kad process ir gatavs izpildei, un laiku, kad procesam ir pieŔķirts procesora laiks.

Virtuālās maŔīnas kodols saņem nozagÅ”anas metriku no hipervizora. Tajā paŔā laikā hipervizors precÄ«zi nenorāda, kādus citus procesus tas darbojas, tas vienkārÅ”i saka: ā€œKamēr esmu aizņemts, es nevaru jums dot laikuā€. KVM ir pievienots zagÅ”anas aprēķina atbalsts ielāpus. Å eit ir divi galvenie punkti:

  • Virtuālā maŔīna uzzina par zagÅ”anu no hipervizora. Tas ir, no zaudējumu viedokļa procesiem paŔā virtuālajā maŔīnā tas ir netieÅ”s mērÄ«jums, kas var tikt pakļauts dažādiem izkropļojumiem.
  • Hipervizors nedalās ar informāciju ar virtuālo maŔīnu par to, ko tā vēl dara ā€“ galvenais, lai tas tam nevelta laiku. Å Ä« iemesla dēļ pati virtuālā maŔīna nevar noteikt izkropļojumus nozagÅ”anas indikatorā, ko varētu novērtēt pēc konkurējoÅ”o procesu rakstura.

2. Kas ietekmē zagÅ”anu

2.1. Nozagt aprēķinu

BÅ«tÄ«bā nozagÅ”ana tiek aprēķināta aptuveni tāpat kā parastais CPU izmantoÅ”anas laiks. Nav daudz informācijas par to, kā tiek uzskatÄ«ta par pārstrādi. Iespējams, tāpēc, ka lielākā daļa cilvēku uzskata, ka Å”is jautājums ir acÄ«mredzams. Bet Å”eit ir arÄ« nepilnÄ«bas. Lai iepazÄ«tos ar Å”o procesu, varat lasÄ«t Brendana Grega raksts: uzzināsiet par daudzām niansēm, aprēķinot izmantoÅ”anu, un par situācijām, kad Å”is aprēķins bÅ«s kļūdains Ŕādu iemeslu dēļ:

  • Procesors pārkarst, izraisot ciklu izlaiÅ”anu.
  • Iespējot/atspējot turbo boost, kas maina procesora takts frekvenci.
  • Laika slāņa garuma izmaiņas, kas rodas, izmantojot procesora enerÄ£ijas taupÄ«Å”anas tehnoloÄ£ijas, piemēram, SpeedStep.
  • Problēma ar vidējā lieluma aprēķināŔanu: vienas minÅ«tes izmantoÅ”anas novērtējums par 80%, var slēpt Ä«slaicÄ«gu 100% pārrāvumu.
  • GrieÅ”anas bloÄ·Ä“Å”ana izraisa procesora atgÅ«Å”anu, bet lietotāja process neredz nekādu progresu tā izpildē. Rezultātā aprēķinātā procesora izmantoÅ”ana procesam bÅ«s simts procenti, lai gan process fiziski nepatērēs procesora laiku.

Neesmu atradis rakstu, kurā bÅ«tu aprakstÄ«ts lÄ«dzÄ«gs aprēķins par zagÅ”anu (ja zini, dalies komentāros). Bet, spriežot pēc pirmkoda, aprēķina mehānisms ir tāds pats kā pārstrādei. VienkārÅ”i kodolā tiek pievienots vēl viens skaitÄ«tājs tieÅ”i KVM procesam (virtuālās maŔīnas process), kas uzskaita KVM procesa ilgumu, gaidot CPU laiku. SkaitÄ«tājs ņem informāciju par procesoru no tā specifikācijām un pārbauda, ā€‹ā€‹vai visas tā atzÄ«mes tiek izmantotas virtuālās maŔīnas procesā. Ja tas ir viss, mēs pieņemam, ka procesors bija aizņemts tikai ar virtuālās maŔīnas procesu. Citādi informējam, ka procesors darÄ«ja ko citu, parādÄ«jās zagÅ”ana.

NozagÅ”anas skaitÄ«Å”anas process ir pakļauts tām paŔām problēmām kā regulāra otrreizējās pārstrādes skaitÄ«Å”ana. Nevar teikt, ka Ŕādas problēmas parādās bieži, taču tās izskatās atturoÅ”i.

2.2. KVM virtualizācijas veidi

Vispārīgi runājot, ir trīs virtualizācijas veidi, kurus visus atbalsta KVM. NozagŔanas mehānisms var būt atkarīgs no virtualizācijas veida.

Apraide. Å ajā gadÄ«jumā virtuālās maŔīnas operētājsistēmas darbÄ«ba ar fiziskām hipervizora ierÄ«cēm notiek Ŕādi:

  1. Viesu operētājsistēma nosūta komandu savai viesa ierīcei.
  2. Viesierīces draiveris saņem komandu, ģenerē pieprasījumu ierīces BIOS un nosūta to hipervizoram.
  3. Hipervizora process pārvērÅ” komandu uz komandu fiziskajai ierÄ«cei, padarot to, cita starpā, droŔāku.
  4. Fiziskās ierÄ«ces draiveris pieņem modificēto komandu un nosÅ«ta to uz paÅ”u fizisko ierÄ«ci.
  5. Komandu izpildes rezultāti atgriežas pa to paŔu ceļu.

TulkoÅ”anas priekÅ”rocÄ«ba ir tāda, ka tā ļauj emulēt jebkuru ierÄ«ci un neprasa Ä«paÅ”u operētājsistēmas kodola sagatavoÅ”anu. Bet par to ir jāmaksā, pirmkārt, ātrumā.

AparatÅ«ras virtualizācija. Å ajā gadÄ«jumā ierÄ«ce aparatÅ«ras lÄ«menÄ« saprot operētājsistēmas komandas. Tas ir ātrākais un labākais veids. Bet diemžēl to neatbalsta visas fiziskās ierÄ«ces, hipervizori un viesu operētājsistēmas. PaÅ”laik galvenās ierÄ«ces, kas atbalsta aparatÅ«ras virtualizāciju, ir procesori.

Paravirtualizācija. VisizplatÄ«tākā ierÄ«ces virtualizācijas iespēja KVM un parasti visizplatÄ«tākais virtualizācijas režīms viesu operētājsistēmām. Tās Ä«patnÄ«ba ir tāda, ka darbs ar dažām hipervizora apakÅ”sistēmām (piemēram, ar tÄ«klu vai diska steku) vai atmiņas lapu pieŔķirÅ”ana notiek, izmantojot hipervizora API, netulkojot zema lÄ«meņa komandas. Å Ä«s virtualizācijas metodes trÅ«kums ir tāds, ka viesu operētājsistēmas kodols ir jāmaina, lai tas varētu sazināties ar hipervizoru, izmantojot Å”o API. Bet tas parasti tiek atrisināts, instalējot Ä«paÅ”us draiverus viesu operētājsistēmā. KVM Å”o API sauc virtio API.

Izmantojot paravirtualizāciju, salÄ«dzinot ar apraidi, ceļŔ uz fizisko ierÄ«ci tiek ievērojami samazināts, nosÅ«tot komandas tieÅ”i no virtuālās maŔīnas uz resursdatora hipervizora procesu. Tas ļauj paātrināt visu instrukciju izpildi virtuālajā maŔīnā. KVM to veic virtio API, kas darbojas tikai noteiktām ierÄ«cēm, piemēram, tÄ«kla vai diska adapterim. Tāpēc virtio draiveri tiek instalēti virtuālajās maŔīnās.

Å Ä« paātrinājuma negatÄ«vā puse ir tāda, ka ne visi procesi, kas darbojas virtuālajā maŔīnā, paliek tajā. Tas rada dažus specefektus, kas var izraisÄ«t nārstoÅ”anu zagÅ”anas gadÄ«jumā. Es iesaku sākt detalizētu Ŕī jautājuma izpēti ar API virtuālajai I/O: virtio.

2.3. "Godīga" plānoŔana

Virtuālā maŔīna uz hipervizora faktiski ir parasts process, kas pakļaujas plānoÅ”anas (resursu sadales starp procesiem) likumiem Linux kodolā, tāpēc apskatÄ«sim to tuvāk.

Linux izmanto tā saukto CFS, Completely Fair Scheduler, kas ir kļuvis par noklusējuma plānotāju kopÅ” kodola 2.6.23. Lai saprastu Å”o algoritmu, varat izlasÄ«t Linux kodola arhitektÅ«ru vai avota kodu. CFS bÅ«tÄ«ba ir sadalÄ«t procesora laiku starp procesiem atkarÄ«bā no to izpildes ilguma. Jo vairāk CPU laika process prasa, jo mazāk CPU laika tas saņem. Tas nodroÅ”ina, ka visi procesi tiek izpildÄ«ti "godÄ«gi" - lai viens process nepārtraukti nenoslogotu visus procesorus, un arÄ« citi procesi var izpildÄ«ties.

Dažreiz Ŕī paradigma noved pie interesantiem artefaktiem. IlgstoÅ”i Linux lietotāji, iespējams, atceras parastā teksta redaktora iesaldÄ“Å”anu darbvirsmā, palaižot resursietilpÄ«gas lietojumprogrammas, piemēram, kompilatoru. Tas notika tāpēc, ka resursietilpÄ«gi uzdevumi darbvirsmas lietojumprogrammās konkurēja ar resursietilpÄ«giem uzdevumiem, piemēram, kompilatoru. CFS uzskata, ka tas ir negodÄ«gi, tāpēc periodiski aptur teksta redaktoru un ļauj procesoram veikt kompilatora uzdevumus. Tas tika labots, izmantojot mehānismu sched_autogroup, taču saglabājās daudzas citas procesora laika sadales funkcijas starp uzdevumiem. PatiesÄ«bā Å”is nav stāsts par to, cik slikti viss ir CFS, bet gan mēģinājums pievērst uzmanÄ«bu tam, ka procesora laika ā€œgodÄ«gaā€ sadale nav tas triviālākais uzdevums.

Vēl viens svarÄ«gs punkts plānotājā ir priekÅ”pirkÅ”ana. Tas ir nepiecieÅ”ams, lai izslēgtu ņirgāŔanos no procesora un ļautu citiem strādāt. IzstumÅ”anas procesu sauc par konteksta maiņu. Å ajā gadÄ«jumā tiek saglabāts viss uzdevuma konteksts: steka stāvoklis, reÄ£istri utt., pēc kura process tiek nosÅ«tÄ«ts gaidÄ«t, un tā vietā tiek nosÅ«tÄ«ts cits. Å Ä« operētājsistēmai ir dārga operācija un tiek reti izmantota, taču tajā nav nekā slikta. Bieža konteksta maiņa var norādÄ«t uz problēmu OS, taču parasti tā ir nepārtraukta un neko Ä«paÅ”i nenorāda.

Tik garÅ” stāsts ir vajadzÄ«gs, lai izskaidrotu vienu faktu: jo vairāk procesora resursu process mēģina patērēt godÄ«gā Linux plānotājā, jo ātrāk tas tiks apturēts, lai varētu darboties arÄ« citi procesi. Tas ir pareizi vai nē, tas ir sarežģīts jautājums, ko dažādās slodzēs var atrisināt atŔķirÄ«gi. Operētājsistēmā Windows vēl nesen plānotājs bija vērsts uz darbvirsmas lietojumprogrammu prioritāro apstrādi, kas varēja izraisÄ«t fona procesu iesaldÄ“Å”anu. Sun Solaris bija piecas dažādas plānotāju klases. Kad mēs uzsākām virtualizāciju, mēs pievienojām sesto, GodÄ«gas daļas plānotājs, jo iepriekŔējās piecas ar Solaris Zones virtualizāciju nedarbojās adekvāti. Es iesaku sākt detalizētu Ŕī jautājuma izpēti ar tādām grāmatām kā Solaris iekŔējie: Solaris 10 un OpenSolaris kodola arhitektÅ«ra vai Linux kodola izpratne.

2.4. Kā uzraudzīt zagŔanu?

NozagÅ”anas uzraudzÄ«ba virtuālajā maŔīnā, tāpat kā jebkura cita procesora metrika, ir vienkārÅ”a: varat izmantot jebkuru procesora metrikas rÄ«ku. Galvenais, lai virtuālā maŔīna bÅ«tu uz Linux. Kādu iemeslu dēļ Windows nesniedz Å”o informāciju saviem lietotājiem. šŸ™

Nozagt: kurŔ zog procesora laiku no virtuālajām maŔīnām
AugŔējās komandas izvade: informācija par procesora slodzi, galējā labajā kolonnā - zagt

GrÅ«tÄ«bas rodas, mēģinot iegÅ«t Å”o informāciju no hipervizora. Varat mēģināt paredzēt zagÅ”anu resursdatorā, piemēram, izmantojot parametru Load Average (LA) - vidējo vērtÄ«bu izpildes rindā gaidoÅ”o procesu skaitam. Å Ä« parametra aprēķināŔanas metode nav vienkārÅ”a, taču kopumā, ja LA, kas normalizēts ar procesora pavedienu skaitu, ir lielāks par 1, tas norāda, ka Linux serveris ir ar kaut ko pārslogots.

Ko visi Å”ie procesi gaida? AcÄ«mredzama atbilde ir procesors. Bet atbilde nav pilnÄ«gi pareiza, jo dažreiz procesors ir brÄ«vs, bet LA nokrÄ«t. Atcerieties kā NFS nokrÄ«t un kā LA aug. Tas pats var notikt ar disku un citām ievades/izvades ierÄ«cēm. Bet patiesÄ«bā procesi var gaidÄ«t jebkuras bloÄ·Ä“Å”anas beigas, vai nu fiziskas, kas saistÄ«tas ar I/O ierÄ«ci, vai loÄ£iskas, piemēram, mutex. Tas ietver arÄ« bloÄ·Ä“Å”anu aparatÅ«ras lÄ«menÄ« (tā pati atbilde no diska) vai loÄ£ikas (tā sauktie bloÄ·Ä“Å”anas primitÄ«vi, kas ietver virkni entÄ«tiju, mutex adaptÄ«vo un spin, semaforus, nosacÄ«jumu mainÄ«gos, rw slēdzenes, ipc slēdzenes ...).

Vēl viena LA iezÄ«me ir tā, ka tā tiek uzskatÄ«ta par operētājsistēmas vidējo rādÄ«tāju. Piemēram, 100 procesi sacenÅ”as par vienu failu, un pēc tam LA=50. Å Ä·iet, ka tik liela vērtÄ«ba norāda, ka operētājsistēma ir slikta. Bet citam greizi rakstÄ«tam kodam tas var bÅ«t normāls stāvoklis, neskatoties uz to, ka tikai tas ir slikts, un citi operētājsistēmas procesi necieÅ”.

Å Ä«s vidējās noteikÅ”anas dēļ (un ne mazāk kā minÅ«tē) kaut ko noteikt pēc LA rādÄ«tāja nav tas atalgojoŔākais uzdevums, jo konkrētos gadÄ«jumos rezultāti ir ļoti neskaidri. Ja mēģināsiet to izdomāt, jÅ«s atklāsiet, ka raksti Vikipēdijā un citos pieejamajos resursos apraksta tikai visvienkārŔākos gadÄ«jumus, bez dziļa procesa skaidrojuma. Atkal sÅ«tu visiem interesentiem, Å”eit Brendanam Gregam  - sekojiet zemāk esoÅ”ajām saitēm. KurÅ” ir pārāk slinks, lai runātu angliski - viņa populārā raksta par LA tulkojums.

3. Specefekti

Tagad apskatÄ«sim galvenos zagÅ”anas gadÄ«jumus, ar kuriem mēs saskārāmies. Es jums pastāstÄ«Å”u, kā tie izriet no visa iepriekÅ” minētā un kā tie attiecas uz hipervizora indikatoriem.

Pārstrāde. VienkārŔākais un visizplatÄ«tākais: hipervizors ir izmantots atkārtoti. PatieŔām, ir daudz darbināmu virtuālo maŔīnu, tajās ir liels procesora patēriņŔ, liela konkurence, LA izmantoÅ”ana ir vairāk nekā 1 (normalizēta ar procesora pavedieniem). Viss visās virtuālajās maŔīnās palēninās. Pieaug arÄ« no hipervizora pārraidÄ«tā zagÅ”ana, nepiecieÅ”ams pārdalÄ«t slodzi vai kādu izslēgt. Kopumā viss ir loÄ£iski un saprotami.

Paravirtualizācija salÄ«dzinājumā ar atseviŔķiem gadÄ«jumiem. Hipervizorā ir tikai viena virtuālā maŔīna; tā patērē nelielu tās daļu, bet rada lielu I/O slodzi, piemēram, diskā. Un no kaut kurienes tajā parādās neliela zagÅ”ana, lÄ«dz 10% (kā liecina vairāki eksperimenti).

Lieta ir interesanta. Steal Å”eit parādās tieÅ”i bloÄ·Ä“Å”anas dēļ paravirtualizētu draiveru lÄ«menÄ«. Virtuālajā maŔīnā tiek izveidots pārtraukums, ko apstrādā draiveris un nosÅ«ta hipervizoram. Hipervizora pārtraukumu apstrādes dēļ virtuālajai maŔīnai tas izskatās kā nosÅ«tÄ«ts pieprasÄ«jums, tas ir gatavs izpildei un gaida procesoru, bet tam netiek dots procesora laiks. Virtuālā meitene domā, ka Å”is laiks ir nozagts.

Tas notiek brÄ«dÄ«, kad tiek nosÅ«tÄ«ts buferis, tas nonāk hipervizora kodola telpā, un mēs sākam to gaidÄ«t. Lai gan no virtuālās maŔīnas viedokļa viņam nekavējoties jāatgriežas. Tāpēc saskaņā ar zagÅ”anas aprēķina algoritmu Å”is laiks tiek uzskatÄ«ts par nozagtu. Visticamāk, Å”ajā situācijā var bÅ«t arÄ« citi mehānismi (piemēram, dažu citu sys zvanu apstrāde), taču tiem nevajadzētu daudz atŔķirties.

Plānotājs pret augsti noslogotām virtuālajām maŔīnām. Ja viena virtuālā maŔīna cieÅ” no zagÅ”anas vairāk nekā citas, tas notiek plānotāja dēļ. Jo vairāk process noslogo procesoru, jo ātrāk plānotājs to izsitÄ«s, lai arÄ« pārējie varētu strādāt. Ja virtuālā maŔīna patērē maz, tā gandrÄ«z neredzēs zagÅ”anu: tās process godÄ«gi sēdēja un gaidÄ«ja, mums ir jādod tai vairāk laika. Ja virtuālā maŔīna rada maksimālo slodzi uz visiem tās kodoliem, tā bieži tiek izmesta no procesora, un viņi cenÅ”as tai nedot daudz laika.

Tas ir vēl sliktāk, ja procesi virtuālajā maŔīnā mēģina iegÅ«t vairāk procesora, jo tie nevar tikt galā ar datu apstrādi. Tad hipervizora operētājsistēma godÄ«gas optimizācijas dēļ nodroÅ”inās arvien mazāk procesora laika. Å is process notiek kā lavÄ«na, un zagÅ”ana lec debesÄ«s, lai gan citas virtuālās maŔīnas to gandrÄ«z nepamanÄ«s. Un jo vairāk kodolu, jo sliktāk ir ietekmētā maŔīna. ÄŖsāk sakot, visvairāk cieÅ” ļoti noslogotas virtuālās maŔīnas ar daudziem kodoliem.

Zema LA, bet ir zagt. Ja LA ir aptuveni 0,7 (tas ir, Ŕķiet, ka hipervizors ir nepietiekami noslogots), bet atseviŔķās virtuālajās maŔīnās tiek novērota zagÅ”ana:

  • IepriekÅ” aprakstÄ«tā opcija ar paravirtualizāciju. Virtuālā maŔīna var saņemt metriku, kas norāda uz zagÅ”anu, lai gan hipervizors ir kārtÄ«bā. Saskaņā ar mÅ«su eksperimentu rezultātiem Ŕī nozagÅ”anas iespēja nepārsniedz 10%, un tai nevajadzētu bÅ«tiski ietekmēt lietojumprogrammu veiktspēju virtuālajā maŔīnā.
  • LA parametrs ir aprēķināts nepareizi. PrecÄ«zāk, katrā konkrētajā brÄ«dÄ« tas tiek aprēķināts pareizi, bet, rēķinot vidēji par vienu minÅ«ti, tas izrādās nenovērtēts. Piemēram, ja viena virtuālā maŔīna uz treÅ”daļu hipervizora patērē visus savus procesorus tieÅ”i pusminÅ«ti, tad LA minÅ«tē hipervizorā bÅ«s 0,15; četras Ŕādas virtuālās maŔīnas, kas strādā vienlaicÄ«gi, dos 0,6. Un to, ka uz katra pusminÅ«ti bija wild steal uz 25% pēc LA rādÄ«tāja, vairs nevar izvilkt.
  • Atkal dēļ plānotāja, kurÅ” nolēma, ka kāds ēd par daudz, un ļāva tam gaidÄ«t. Tikmēr es pārslēgÅ”u kontekstu, apstrādāŔu pārtraukumus un parÅ«pÄ“Å”os par citām svarÄ«gām sistēmas lietām. Rezultātā dažas virtuālās maŔīnas nesaskata nekādas problēmas, savukārt citas piedzÄ«vo nopietnu veiktspējas pasliktināŔanos.

4. Citi kropļojumi

Ir vēl miljons iemeslu, lai izkropļotu godÄ«gu procesora laika atdevi virtuālajā maŔīnā. Piemēram, hiperpavediens un NUMA rada grÅ«tÄ«bas aprēķinos. Tie pilnÄ«bā sajauc kodola izvēli procesa izpildei, jo plānotājs izmanto koeficientus - svarus, kas, pārslēdzot kontekstu, aprēķinu padara vēl grÅ«tāku.

Izkropļojumi rodas tādu tehnoloÄ£iju dēļ kā turbo boost vai, gluži otrādi, enerÄ£ijas taupÄ«Å”anas režīms, kas, aprēķinot noslodzi, var mākslÄ«gi palielināt vai samazināt servera frekvenci vai pat laika Ŕķēli. Turbo boost iespējoÅ”ana samazina viena procesora pavediena veiktspēju, jo palielinās cita procesora veiktspēja. Å obrÄ«d uz virtuālo maŔīnu netiek pārsÅ«tÄ«ta informācija par paÅ”reizējo procesora frekvenci, un tā uzskata, ka kāds zog tās laiku (piemēram, prasÄ«ja 2 GHz, bet saņēma pusi mazāk).

Kopumā izkropļojumam var bÅ«t daudz iemeslu. JÅ«s varat atrast kaut ko citu konkrētā sistēmā. Labāk ir sākt ar grāmatām, uz kurām iepriekÅ” sniedzu saites, un statistikas izgÅ«Å”anu no hipervizora, izmantojot tādas utilÄ«tas kā perf, sysdig, systemtap, no kurām desmitiem.

5. Secinājumi

  1. Paravirtualizācijas dēļ var rasties zināms zagÅ”anas apjoms, un to var uzskatÄ«t par normālu. Viņi raksta internetā, ka Ŕī vērtÄ«ba var bÅ«t 5-10%. Tas ir atkarÄ«gs no lietojumprogrammām virtuālajā maŔīnā un no slodzes, ko tā rada savām fiziskajām ierÄ«cēm. Å eit ir svarÄ«gi pievērst uzmanÄ«bu tam, kā lietojumprogrammas jÅ«tas virtuālajās maŔīnās.
  2. Hipervizora slodzes un zagÅ”anas attiecÄ«ba virtuālajā maŔīnā ne vienmēr ir skaidri savstarpēji saistÄ«ta; abi zagÅ”anas aprēķini var bÅ«t kļūdaini noteiktās situācijās ar dažādām slodzēm.
  3. Plānotājam ir slikta attieksme pret procesiem, kas prasa daudz. ViņŔ cenÅ”as dot mazāk tiem, kas prasa vairāk. Lielas virtuālās maŔīnas ir ļaunas.
  4. Neliela zagÅ”ana var bÅ«t norma pat bez paravirtualizācijas (ņemot vērā slodzi virtuālajā maŔīnā, kaimiņu slodzes Ä«paŔības, slodzes sadalÄ«jumu pa pavedieniem un citus faktorus).
  5. Ja vēlaties izdomāt zagÅ”anu konkrētā sistēmā, jums ir jāizpēta dažādas iespējas, jāapkopo rādÄ«tāji, rÅ«pÄ«gi jāanalizē un jādomā, kā vienmērÄ«gi sadalÄ«t slodzi. Ir iespējamas novirzes no jebkuriem gadÄ«jumiem, kas ir jāapstiprina eksperimentāli vai jāapskata kodola atkļūdotājs.

Avots: www.habr.com

Pievieno komentāru