Steal: kdo krade procesorski čas virtualnim strojem

Steal: kdo krade procesorski čas virtualnim strojem

Zdravo! Na preprost način vam želim povedati o mehaniki kraje znotraj virtualnih strojev in o nekaterih neočitnih artefaktih, ki smo jih uspeli odkriti med raziskavo, v katero sem se moral poglobiti kot tehnični direktor platforme v oblaku. Mail.ru rešitve v oblaku. Platforma deluje na KVM.

CPE steal time je čas, v katerem navidezni stroj ne prejme procesorskih virov za svoje izvajanje. Ta čas se šteje le v gostujočih operacijskih sistemih v virtualizacijskih okoljih. Razlogi, kam gredo ta najbolj dodeljena sredstva, so tako kot v življenju zelo nejasni. Vendar smo se odločili, da to ugotovimo, in celo izvedli številne poskuse. Ne gre za to, da zdaj vemo vse o kraji, vendar vam bomo zdaj povedali nekaj zanimivega.

1. Kaj je ukrasti

Kraja je torej metrika, ki kaže na pomanjkanje procesorskega časa za procese znotraj virtualnega stroja. Kot je opisano v popravku jedra KVMPrikritost je čas, v katerem hipervizor izvaja druge procese v OS gostitelja, čeprav je proces navideznega stroja postavil v čakalno vrsto za izvajanje. To pomeni, da se kraja izračuna kot razlika med časom, ko je proces pripravljen za izvedbo, in časom, ko je procesu dodeljen procesorski čas.

Jedro navideznega stroja prejme metriko kraje od hipervizorja. Hkrati pa hipervizor ne določa natančno, katere druge procese izvaja, preprosto pravi "dokler sem zaposlen, vam ne morem dati časa." Na KVM je bila dodana podpora za izračun kraje obliži. Tukaj sta dve ključni točki:

  • Virtualni stroj izve za krajo iz hipervizorja. Se pravi, z vidika izgub je za procese na samem virtualnem stroju to posredna meritev, ki je lahko podvržena različnim popačenjem.
  • Hipervizor z virtualnim strojem ne deli informacij o tem, kaj še počne - glavna stvar je, da temu ne posveča časa. Zaradi tega virtualni stroj sam ne more zaznati izkrivljanj v indikatorju kraje, ki bi jih lahko ocenili glede na naravo konkurenčnih procesov.

2. Kaj vpliva na krajo

2.1. Izračun kraje

Kraja se v bistvu izračuna približno enako kot običajni čas uporabe procesorja. Ni veliko informacij o tem, kako se upošteva recikliranje. Verjetno zato, ker večina ljudi meni, da je to vprašanje očitno. A tu so tudi pasti. Če se želite seznaniti s tem postopkom, lahko preberete članek Brendana Gregga: izvedeli boste o številnih odtenkih pri izračunu izkoriščenosti in o situacijah, ko bo ta izračun napačen iz naslednjih razlogov:

  • Procesor se pregreje, kar povzroči preskoke ciklov.
  • Omogoči/onemogoči Turbo Boost, ki spremeni hitrost procesorja.
  • Sprememba dolžine časovne rezine, do katere pride pri uporabi tehnologij za varčevanje z energijo procesorja, kot je SpeedStep.
  • Težava pri izračunu povprečja: ocena izkoriščenosti ene minute na 80 % lahko prikrije kratkoročni izbruh 100 %.
  • Spin lock povzroči, da se procesor ponovno zahteva, vendar uporabniški proces ne opazi nobenega napredka pri svojem izvajanju. Posledično bo izračunana izkoriščenost procesorja s procesom stoodstotna, čeprav proces fizično ne bo porabil procesorskega časa.

Nisem našel članka, ki bi opisoval podoben izračun za krajo (če veste, ga delite v komentarjih). Toda, sodeč po izvorni kodi, je mehanizem izračuna enak kot pri recikliranju. Preprosto, v jedru je dodan še en števec, neposredno za proces KVM (proces navideznega stroja), ki šteje trajanje procesa KVM, ki čaka na CPE čas. Števec vzame informacije o procesorju iz njegove specifikacije in preveri, ali proces navideznega stroja uporablja vse njegove kljukice. Če je to vse, potem predpostavljamo, da je bil procesor zaseden samo s procesom navideznega stroja. Sicer sporočamo, da je procesor počel nekaj drugega, pojavila se je kraja.

Postopek štetja ukradenih odpadkov je predmet enakih težav kot običajno štetje recikliranja. Ne rečem, da se takšne težave pojavljajo pogosto, vendar izgledajo odvračajoče.

2.2. Vrste virtualizacije na KVM

Na splošno obstajajo tri vrste virtualizacije, vse pa podpira KVM. Mehanizem nastanka kraje je lahko odvisen od vrste virtualizacije.

Oddaja. V tem primeru se delovanje operacijskega sistema virtualnega stroja s fizičnimi hipervizorskimi napravami zgodi nekako takole:

  1. Gostujoči operacijski sistem pošlje ukaz svoji gostujoči napravi.
  2. Gostujoči gonilnik naprave prejme ukaz, ustvari zahtevo za BIOS naprave in jo pošlje hipervizorju.
  3. Postopek hipervizorja prevaja ukaz v ukaz za fizično napravo, zaradi česar je med drugim varnejša.
  4. Gonilnik fizične naprave sprejme spremenjen ukaz in ga pošlje sami fizični napravi.
  5. Rezultati izvajanja ukazov se vračajo po isti poti.

Prednost prevajanja je, da omogoča posnemanje katere koli naprave in ne zahteva posebne priprave jedra operacijskega sistema. Toda za to morate najprej plačati s hitrostjo.

Virtualizacija strojne opreme. V tem primeru naprava na ravni strojne opreme razume ukaze iz operacijskega sistema. To je najhitrejši in najboljši način. Toda na žalost je ne podpirajo vse fizične naprave, hipervizorji in gostujoči operacijski sistemi. Trenutno so glavne naprave, ki podpirajo virtualizacijo strojne opreme, procesorji.

Paravirtualizacija. Najpogostejša možnost za virtualizacijo naprave na KVM in na splošno najpogostejši način virtualizacije za gostujoče operacijske sisteme. Njegova posebnost je, da delo z nekaterimi podsistemi hipervizorja (na primer z omrežjem ali diskovnim skladom) ali dodeljevanje pomnilniških strani poteka z uporabo API-ja hipervizorja brez prevajanja ukazov na nizki ravni. Pomanjkljivost te virtualizacijske metode je, da je treba jedro gostujočega operacijskega sistema spremeniti tako, da lahko komunicira s hipervizorjem s tem API-jem. Toda to se običajno reši z namestitvijo posebnih gonilnikov v gostujoči operacijski sistem. V KVM se ta API kliče virtio API.

S paravirtualizacijo se v primerjavi z oddajanjem pot do fizične naprave bistveno skrajša s pošiljanjem ukazov neposredno iz virtualnega stroja v proces hipervizorja na gostitelju. To vam omogoča, da pospešite izvajanje vseh navodil v virtualnem stroju. V KVM to naredi virtio API, ki deluje samo za določene naprave, kot je omrežni ali diskovni adapter. Zato so gonilniki virtio nameščeni znotraj virtualnih strojev.

Slaba stran tega pospeševanja je, da vsi procesi, ki tečejo v virtualnem stroju, ne ostanejo v njem. To ustvari nekaj posebnih učinkov, ki lahko povzročijo drstenje ob kraji. Priporočam, da začnete s podrobno študijo tega vprašanja API za virtualni V/I: virtio.

2.3. "Pravično" razporejanje

Virtualni stroj na hipervizorju je pravzaprav navaden proces, ki upošteva zakone razporejanja (distribucije virov med procesi) v jedru Linuxa, zato si ga poglejmo pobližje.

Linux uporablja tako imenovani CFS, Completely Fair Scheduler, ki je od jedra 2.6.23 postal privzeti razporejevalnik. Za razumevanje tega algoritma lahko preberete arhitekturo jedra Linuxa ali izvorno kodo. Bistvo CFS je porazdelitev procesorskega časa med procesi glede na trajanje njihovega izvajanja. Več procesorskega časa potrebuje proces, manj procesorskega časa prejme. S tem zagotovimo, da se vsi procesi izvajajo »pošteno« – da en proces ne zaseda stalno vseh procesorjev in se lahko izvajajo tudi drugi procesi.

Včasih ta paradigma vodi do zanimivih artefaktov. Dolgoletni uporabniki Linuxa se verjetno spomnijo zamrznitve običajnega urejevalnika besedil na namizju med izvajanjem aplikacij, ki zahtevajo veliko virov, kot je prevajalnik. To se je zgodilo, ker so naloge, ki ne zahtevajo virov, v namiznih aplikacijah tekmovale z nalogami, ki zahtevajo vire, kot je prevajalnik. CFS meni, da je to nepošteno, zato občasno ustavi urejevalnik besedil in prepusti procesorju, da opravi naloge prevajalnika. To je bilo popravljeno z mehanizmom sched_autogroup, vendar je ostalo veliko drugih funkcij porazdelitve procesorskega časa med nalogami. Pravzaprav to ni zgodba o tem, kako slabo je vse v CFS, ampak poskus opozoriti na dejstvo, da "pravična" porazdelitev procesorskega časa ni najbolj trivialna naloga.

Druga pomembna točka v razporejevalniku je prednostna naloga. To je potrebno, da iz procesorja izločimo proces snickeringa in drugim omogočimo delo. Postopek izvrževanja se imenuje preklapljanje konteksta. V tem primeru se ohrani celoten kontekst naloge: stanje sklada, registrov itd., Po katerem se proces pošlje na čakanje, na njegovo mesto pa pride drug. To je draga operacija za OS in se redko uporablja, vendar s tem ni nič narobe. Pogosto preklapljanje konteksta lahko kaže na težavo v operacijskem sistemu, vendar je običajno stalno in ne kaže ničesar posebnega.

Tako dolga zgodba je potrebna za razlago enega dejstva: več virov procesorja poskuša porabiti proces v poštenem razporejevalniku Linuxa, hitreje bo ustavljen, tako da lahko delujejo tudi drugi procesi. Ali je to pravilno ali ne, je zapleteno vprašanje, ki ga je pri različnih obremenitvah mogoče rešiti različno. V sistemu Windows je bil razporejevalnik do nedavnega osredotočen na prednostno obdelavo namiznih aplikacij, kar bi lahko povzročilo zamrznitev procesov v ozadju. Sun Solaris je imel pet različnih razredov urnikov. Ko smo lansirali virtualizacijo, smo dodali še šesto, Razporejevalnik pravičnih deležev, ker prejšnjih pet ni ustrezno delovalo z virtualizacijo Solaris Zones. Priporočam, da začnete podrobno preučevati to vprašanje s knjigami, kot je Notranjost Solarisa: Solaris 10 in arhitektura jedra OpenSolaris ali Razumevanje jedra Linuxa.

2.4. Kako spremljati krajo?

Spremljanje kraje znotraj navideznega stroja je, tako kot katera koli druga meritev procesorja, preprosto: uporabite lahko katero koli orodje za meritve procesorja. Glavna stvar je, da je virtualni stroj na Linuxu. Windows iz neznanega razloga teh informacij ne posreduje svojim uporabnikom. 🙁

Steal: kdo krade procesorski čas virtualnim strojem
Izhod zgornjega ukaza: podrobnosti o obremenitvi procesorja, v skrajnem desnem stolpcu - ukrasti

Težava se pojavi pri poskusu pridobitve teh informacij od hipervizorja. Lahko poskusite predvideti krajo na gostiteljskem računalniku, na primer z uporabo parametra Load Average (LA) – povprečne vrednosti števila procesov, ki čakajo v čakalni vrsti za izvajanje. Metoda za izračun tega parametra ni preprosta, toda na splošno, če je LA, normaliziran s številom procesorskih niti, večji od 1, to pomeni, da je strežnik Linux z nečim preobremenjen.

Kaj vsi ti procesi čakajo? Očiten odgovor je procesor. Toda odgovor ni povsem pravilen, saj je včasih procesor brezplačen, vendar LA izgine. Ne pozabite kako NFS odpade in kako LA raste. Enako se lahko zgodi z diskom in drugimi vhodno/izhodnimi napravami. Toda dejansko lahko procesi počakajo na konec katerega koli zaklepanja, bodisi fizičnega, povezanega z V/I napravo, ali logičnega, kot je mutex. Sem spada tudi zaklepanje na nivoju strojne opreme (enaki odziv diska), ali logike (t. i. locking primitives, ki vključuje kup entitet, mutex adaptive in spin, semaforje, spremenljivke stanja, rw ključavnice, ipc ključavnice ...).

Druga značilnost LA je, da velja za povprečje operacijskega sistema. Na primer, 100 procesov tekmuje za eno datoteko, nato pa LA=50. Zdi se, da tako velika vrednost pomeni, da je operacijski sistem slab. Toda za drugo krivo napisano kodo je to lahko normalno stanje, kljub dejstvu, da je le slabo, drugi procesi v operacijskem sistemu pa ne trpijo.

Zaradi tega povprečenja (in to v nič manj kot minuti) določanje česar koli z indikatorjem LA ni najbolj nagrajujoča naloga, z zelo negotovimi rezultati v posebnih primerih. Če poskusite ugotoviti, boste ugotovili, da članki na Wikipediji in drugih razpoložljivih virih opisujejo le najpreprostejše primere, brez poglobljene razlage postopka. Vsem zainteresiranim pošiljam ponovno, tukaj Brendanu Greggu  - sledite spodnjim povezavam. Kdo je prelen, da bi govoril angleško - prevod njegovega priljubljenega članka o LA.

3. Posebni učinki

Zdaj pa si poglejmo glavne primere kraje, s katerimi smo se srečali. Povedal vam bom, kako sledijo vsemu zgoraj navedenemu in kako so povezani z indikatorji na hipervizorju.

Recikliranje. Najenostavnejši in najpogostejši: hipervizor je bil ponovno uporabljen. Dejansko je veliko delujočih virtualnih strojev, velika poraba procesorja v njih, velika konkurenca, izkoriščenost LA je večja od 1 (normalizirana s procesorskimi nitmi). Vse znotraj vseh virtualnih strojev se upočasni. Tudi kraje, ki se prenašajo iz hipervizorja, rastejo, treba je prerazporediti obremenitev ali nekoga izključiti. Na splošno je vse logično in razumljivo.

Paravirtualizacija proti posameznim primerkom. Na hipervizorju je samo en navidezni stroj; porabi ga majhen del, vendar povzroči veliko V/I obremenitev, na primer na disku. In od nekje se v njem pojavi majhen ukradeni delež, do 10% (kot je pokazalo več poskusov).

Zadeva je zanimiva. Steal se tukaj pojavi ravno zaradi blokade na ravni paravirtualiziranih gonilnikov. Znotraj virtualnega stroja se ustvari prekinitev, gonilnik jo obdela in pošlje hipervizorju. Zaradi obdelave prekinitev na hipervizorju je za virtualni stroj videti kot poslana zahteva, je pripravljen za izvedbo in čaka na procesor, vendar mu ni dodeljen procesorski čas. Virtualno dekle misli, da je ta čas ukraden.

To se zgodi v trenutku, ko je medpomnilnik poslan, gre v prostor jedra hipervizorja in začnemo čakati nanj. Čeprav bi se moral z vidika virtualnega stroja takoj vrniti. Zato se glede na algoritem za izračun kraje ta čas šteje za ukraden. Najverjetneje v tej situaciji morda obstajajo drugi mehanizmi (na primer obdelava nekaterih drugih sistemskih klicev), vendar ne bi smeli biti veliko drugačni.

Razporejevalnik v primerjavi z visoko obremenjenimi virtualnimi stroji. Ko en virtualni stroj trpi zaradi kraje bolj kot drugi, je to posledica razporejevalnika. Bolj kot proces obremeni procesor, prej ga bo razporejevalnik izgnal, da bodo tudi drugi lahko delovali. Če virtualni stroj porabi malo, skoraj ne bo videl krade: njegov proces je pošteno sedel in čakal, dati mu moramo več časa. Če navidezni stroj povzroči največjo obremenitev vseh svojih jeder, ga pogosto vržejo iz procesorja in poskušajo mu ne dati veliko časa.

Še huje je, ko procesi znotraj navideznega stroja poskušajo dobiti več procesorja, ker niso kos obdelavi podatkov. Takrat bo operacijski sistem na hipervizorju zaradi poštene optimizacije zagotavljal vedno manj procesorskega časa. Ta proces poteka kot plaz in kraja skoči v nebo, čeprav ga drugi virtualni stroji komaj opazijo. In več kot je jeder, slabše je prizadet stroj. Skratka, najbolj trpijo visoko obremenjeni virtualni stroji z veliko jedri.

Nizek LA, vendar je kraja. Če je LA približno 0,7 (to pomeni, da je hipervizor videti premalo obremenjen), vendar je opaziti krajo znotraj posameznih virtualnih strojev:

  • Možnost s paravirtualizacijo, ki je že opisana zgoraj. Virtualni stroj lahko prejme meritve, ki kažejo na krajo, čeprav je hipervizor v redu. Glede na rezultate naših poskusov ta možnost kraje ne presega 10 % in ne bi smela bistveno vplivati ​​na delovanje aplikacij v virtualnem stroju.
  • Parameter LA je napačno izračunan. Natančneje, v vsakem posameznem trenutku je izračunana pravilno, vendar se pri povprečenju v eni minuti izkaže za podcenjeno. Na primer, če en virtualni stroj na tretjino hipervizorja porabi vse svoje procesorje točno pol minute, bo LA na minuto na hipervizorju 0,15; štirje takšni virtualni stroji, ki delujejo hkrati, bodo dali 0,6. In to, da je bil pol minute na vsakem wild steal na 25% po LA indikatorju, se ne da več potegniti.
  • Spet zaradi urnika, ki se je odločil, da nekdo preveč poje in naj ta nekdo počaka. Medtem bom zamenjal kontekst, obravnaval prekinitve in poskrbel za druge pomembne sistemske stvari. Posledično nekateri virtualni stroji ne opazijo nobenih težav, drugi pa občutijo resno poslabšanje delovanja.

4. Druga popačenja

Razlogov za izkrivljanje pravičnega donosa procesorskega časa na virtualnem stroju je še milijon. Hipernitnost in NUMA na primer predstavljata težave pri izračunih. Popolnoma zmedejo izbiro jedra za izvajanje procesa, saj planer uporablja koeficiente - uteži, ki pri preklapljanju konteksta še dodatno otežijo izračun.

Obstajajo izkrivljanja zaradi tehnologij, kot je turbo boost ali, nasprotno, način varčevanja z energijo, ki lahko pri izračunu izkoriščenosti umetno povečajo ali zmanjšajo frekvenco ali celo časovno rezino na strežniku. Omogočanje Turbo Boost zmanjša zmogljivost ene niti procesorja zaradi povečanja zmogljivosti druge. V tem trenutku se informacija o trenutni frekvenci procesorja ne posreduje virtualnemu stroju in verjame, da mu nekdo krade čas (na primer, zahteval je 2 GHz, prejel pa polovico).

Na splošno je lahko veliko razlogov za izkrivljanje. Morda boste v določenem sistemu našli kaj drugega. Bolje je začeti s knjigami, do katerih sem dal povezave zgoraj, in s pridobivanjem statističnih podatkov iz hipervizorja z uporabo pripomočkov, kot so perf, sysdig, systemtap, od katerih desetine.

5. Sklepi

  1. Zaradi paravirtualizacije lahko pride do določene količine kraje in se lahko šteje za normalno. Na internetu pišejo, da je ta vrednost lahko 5-10%. Odvisno od aplikacij znotraj navideznega stroja in od obremenitve, ki jo ima na svojih fizičnih napravah. Tukaj je pomembno biti pozoren na to, kako se aplikacije počutijo znotraj virtualnih strojev.
  2. Razmerje med obremenitvijo hipervizorja in krajo znotraj virtualnega stroja ni vedno jasno med seboj povezano; obe oceni kraje sta lahko napačni v določenih situacijah pod različnimi obremenitvami.
  3. Razporejevalnik ima slab odnos do procesov, ki zahtevajo veliko. Tistim, ki zahtevajo več, poskuša dati manj. Veliki virtualni stroji so zlo.
  4. Majhna kraja je lahko norma tudi brez paravirtualizacije (ob upoštevanju obremenitve znotraj virtualnega stroja, značilnosti obremenitve sosedov, porazdelitve obremenitve po nitih in drugih dejavnikov).
  5. Če želite ugotoviti krajo v določenem sistemu, morate raziskati različne možnosti, zbrati metrike, jih natančno analizirati in razmisliti o tem, kako enakomerno porazdeliti obremenitev. Možna so odstopanja od poljubnih primerov, ki jih je treba eksperimentalno potrditi ali pogledati v razhroščevalniku jedra.

Vir: www.habr.com

Dodaj komentar