Sveiki! Noriu paprastai papasakoti apie vagysčių atsiradimo virtualiose mašinose mechaniką ir apie kai kuriuos neakivaizdžius artefaktus, kuriuos pavyko išsiaiškinti jo tyrimo metu, į kuriuos man teko pasinerti kaip debesų platformos techniniam direktoriui. . Platforma veikia KVM.
CPU pavogimo laikas yra laikas, per kurį virtuali mašina negauna procesoriaus išteklių savo vykdymui. Į šį laiką atsižvelgiama tik svečių operacinėse sistemose virtualizacijos aplinkose. Priežastys, kur nukeliauja šie skirti ištekliai, kaip ir gyvenime, labai neaiškios. Bet mes nusprendėme tai išsiaiškinti, netgi surengėme daugybę eksperimentų. Tai nereiškia, kad mes dabar viską žinome apie vagystę, bet dabar papasakosime kai ką įdomaus.
1. Kas yra vagystė
Taigi pavogimas yra metrika, rodanti, kad virtualioje mašinoje vykstantiems procesams trūksta procesoriaus laiko. Kaip aprašyta , pavogimas yra laikas, per kurį hipervizorius vykdo kitus procesus pagrindinio kompiuterio OS, net jei jis yra įtraukęs į eilę virtualios mašinos proceso vykdymui. Tai yra, pavogimas apskaičiuojamas kaip skirtumas tarp laiko, kai procesas yra paruoštas paleisti, ir laiko, kai procesui skiriamas procesoriaus laikas.
Virtualios mašinos branduolys gauna pavogimo metriką iš hipervizoriaus. Tuo pačiu metu hipervizorius nenurodo, kokius kitus procesus jis atlieka, tiesiog „kol aš užsiėmęs, negaliu jums skirti laiko“. KVM yra įtrauktas pavogimo skaičiavimo palaikymas . Čia yra du pagrindiniai punktai:
- Virtuali mašina sužino apie vagystę iš hipervizoriaus. Tai yra, nuostolių požiūriu, procesams, vykstantiems pačioje virtualioje mašinoje, tai yra netiesioginis matavimas, kuris gali būti įvairių iškraipymų.
- Hipervizorius nesidalija informacija su virtualia mašina apie tai, ką dar daro – svarbiausia, kad neskirtų tam laiko. Dėl šios priežasties pati virtuali mašina negali aptikti vagystės rodiklio iškraipymų, kuriuos būtų galima įvertinti pagal konkuruojančių procesų pobūdį.
2. Kas turi įtakos vagystei
2.1. Pavogti skaičiavimą
Tiesą sakant, vagystė vertinama taip pat, kaip įprastas procesoriaus naudojimo laikas. Nėra daug informacijos apie tai, kaip svarstomas perdirbimas. Tikriausiai todėl, kad dauguma šį klausimą laiko akivaizdžiu. Tačiau čia taip pat yra spąstų. Norėdami apžvelgti šį procesą, skaitykite : sužinosite apie daugybę niuansų skaičiuodami panaudojimą ir apie situacijas, kai šis skaičiavimas bus klaidingas dėl šių priežasčių:
- Procesoriaus perkaitimas, kai ciklai praleidžiami.
- Įjungti / išjungti turbo boost, kuris keičia procesoriaus laikrodžio dažnį.
- Laiko pjūvio ilgio pokytis, atsirandantis naudojant procesoriaus energijos taupymo technologijas, pvz., „SpeedStep“.
- Vidutinės problemos apskaičiavimas: vienos minutės 80% išnaudojimo įvertinimas gali paslėpti trumpalaikį 100% sprogimą.
- Dėl sukimosi užrakto procesorius atkuriamas, tačiau vartotojo procesas nemato jo vykdymo pažangos. Dėl to numatomas procesoriaus panaudojimas bus XNUMX%, nors procesas fiziškai nesunaudos procesoriaus laiko.
Neradau straipsnio, kuriame būtų aprašytas panašus vagystės skaičiavimas (jei žinote, pasidalinkite komentaruose). Tačiau, sprendžiant iš šaltinių, skaičiavimo mechanizmas yra toks pat kaip ir perdirbant. Tiesiog branduolyje yra pridėtas kitas skaitiklis, skirtas tiesiogiai KVM procesui (virtualios mašinos procesas), kuris skaičiuoja KVM proceso trukmę procesoriaus laukimo būsenoje. Skaitiklis paima informaciją apie procesorių iš jo specifikacijų ir mato, ar virtualios mašinos procesas išnaudoja visas jo žymes. Jei viskas, tada manome, kad procesorius dalyvavo tik virtualios mašinos procese. Kitu atveju informuojame, kad procesorius dar kažką darė, atsirado vogimas.
Pavogimų skaičiavimo procesas susiduria su tomis pačiomis problemomis kaip ir įprastas vagysčių skaičiavimas. Negalima sakyti, kad tokių problemų atsiranda dažnai, bet jos atrodo atgrasančios.
2.2. KVM virtualizacijos tipai
Paprastai kalbant, yra trys virtualizacijos tipai, ir visus juos palaiko KVM. Vagystės atsiradimo mechanizmas gali priklausyti nuo virtualizacijos tipo.
Transliuoti. Šiuo atveju virtualios mašinos operacinės sistemos darbas su fiziniais hipervizoriaus įrenginiais vyksta maždaug taip:
- Svečio operacinė sistema siunčia komandą savo svečio įrenginiui.
- Svečio įrenginio tvarkyklė gauna komandą, sugeneruoja įrenginio BIOS užklausą ir siunčia ją hipervizoriui.
- Hipervizoriaus procesas paverčia komandą fizinio įrenginio komanda, todėl ji, be kita ko, yra saugesnė.
- Fizinio įrenginio tvarkyklė priima pakeistą komandą ir siunčia ją pačiam fiziniam įrenginiui.
- Komandų vykdymo rezultatai grįžta tuo pačiu keliu.
Vertimo pranašumas yra tas, kad jis leidžia emuliuoti bet kurį įrenginį ir nereikalauja specialaus operacinės sistemos branduolio paruošimo. Tačiau už tai pirmiausia turite mokėti greitai.
Aparatinės įrangos virtualizavimas. Šiuo atveju įrenginys aparatūros lygiu supranta operacinės sistemos komandas. Tai greičiausias ir geriausias būdas. Bet, deja, jį palaiko ne visi fiziniai įrenginiai, hipervizoriai ir svečių operacinės sistemos. Šiuo metu pagrindiniai įrenginiai, palaikantys aparatinės įrangos virtualizavimą, yra procesoriai.
Paravirtualizacija. Dažniausias įrenginio virtualizavimo KVM variantas ir apskritai labiausiai paplitęs svečių operacinės sistemos virtualizacijos režimas. Jo ypatumas yra tas, kad darbas su kai kuriomis hipervizoriaus posistemėmis (pavyzdžiui, su tinklu ar disko krūva) arba atminties puslapių paskirstymas vyksta naudojant hipervizoriaus API, neverčiant žemo lygio komandų. Šio virtualizacijos metodo trūkumas yra tas, kad svečio operacinės sistemos branduolį reikia modifikuoti, kad jis galėtų susisiekti su hipervizoriumi naudodamas šią API. Bet dažniausiai tai išsprendžiama įdiegus specialias tvarkykles svečių operacinėje sistemoje. KVM ši API vadinama .
Naudojant paravirtualizaciją, lyginant su vertimu, kelias į fizinį įrenginį gerokai sumažinamas, siunčiant komandas tiesiai iš virtualios mašinos į pagrindinio kompiuterio hipervizoriaus procesą. Tai leidžia pagreitinti visų instrukcijų vykdymą virtualioje mašinoje. KVM už tai atsakinga virtio API, kuri veikia tik tam tikruose įrenginiuose, pavyzdžiui, tinklo ar disko adapteryje. Štai kodėl virtio tvarkyklės yra įdiegtos virtualiose mašinose.
Atvirkštinė šio pagreičio pusė yra ta, kad ne visi procesai, vykstantys virtualioje mašinoje, lieka joje. Taip sukuriami specialieji efektai, dėl kurių gali atsirasti pavogimas. Rekomenduoju pradėti išsamų šios problemos tyrimą .
2.3. „Sąžiningas“ tvarkaraštis
Virtuali mašina hipervizoriuje iš tikrųjų yra įprastas procesas, paklūstantis planavimo (resursų paskirstymo tarp procesų) dėsniams Linux branduolyje, todėl pažvelkime į tai atidžiau.
Linux naudoja vadinamąjį CFS, Completely Fair Scheduler, kuris tapo numatytuoju planuokliu nuo branduolio 2.6.23 versijos. Norėdami suprasti šį algoritmą, galite perskaityti Linux branduolio architektūrą arba šaltinį. CFS esmė yra procesoriaus laiko paskirstymas tarp procesų, priklausomai nuo jų vykdymo trukmės. Kuo daugiau procesoriaus laiko reikia procesui, tuo mažiau procesoriaus laiko jis gauna. Tai garantuoja „sąžiningą“ visų procesų vykdymą – kad vienas procesas neužimtų visą laiką visų procesorių, o kiti procesai taip pat gali būti vykdomi.
Kartais ši paradigma veda prie įdomių artefaktų. Ilgamečiai „Linux“ naudotojai tikrai prisimins įprasto teksto rengyklės užstrigimą darbalaukyje paleidžiant daug išteklių reikalaujančias programas, tokias kaip kompiliatorius. Taip atsitiko todėl, kad resursų nereikalaujančios darbalaukio programų užduotys konkuravo su aktyviai išteklius vartojančiomis užduotimis, tokiomis kaip kompiliatorius. CFS mano, kad tai nesąžininga, todėl periodiškai sustabdo teksto rengyklę ir leidžia procesoriui atlikti kompiliatoriaus užduotis. Tai buvo ištaisyta naudojant mechanizmą , tačiau išliko daug kitų procesoriaus laiko paskirstymo tarp užduočių ypatybių. Tiesą sakant, ši istorija ne apie tai, kaip viskas blogai CFS, o bandymas atkreipti dėmesį į tai, kad „teisingas“ procesoriaus laiko paskirstymas nėra pati menkiausia užduotis.
Kitas svarbus planuotojo punktas yra išankstinė teisė. Tai būtina norint pašalinti šnibždėjimo procesą iš procesoriaus ir leisti kitiems dirbti. Tremties procesas vadinamas konteksto perjungimu, procesoriaus konteksto perjungimu. Tuo pačiu išsaugomas visas užduoties kontekstas: kamino būsena, registrai ir pan., po to procesas siunčiamas laukti, o jo vietą užima kitas. Tai brangi operacija OS ir retai naudojama, tačiau iš tikrųjų joje nėra nieko blogo. Dažnas konteksto perjungimas gali reikšti OS problemą, tačiau dažniausiai tai vyksta nuolat ir nieko konkrečiai nenurodo.
Tokios ilgos istorijos reikia norint paaiškinti vieną faktą: kuo daugiau procesoriaus resursų procesas bando sunaudoti sąžiningame Linux planuoklyje, tuo greičiau jis bus sustabdytas, kad galėtų veikti ir kiti procesai. Ar tai teisinga, ar ne – sunkus klausimas, kuris, esant įvairioms apkrovoms, išsprendžiamas skirtingai. „Windows“ sistemoje iki šiol planuotojas buvo sutelktas į prioritetinį darbalaukio programų apdorojimą, dėl kurio foniniai procesai galėjo užstrigti. „Sun Solaris“ turėjo penkias skirtingas planuotojų klases. Kai buvo paleista virtualizacija, buvo pridėta šeštoji, nes ankstesnės penkios tinkamai neveikė su Solaris Zones virtualizavimu. Rekomenduoju pradėti išsamų šios problemos tyrimą su tokiomis knygomis kaip arba .
2.4. Kaip stebėti vagystę?
Stebėti vagystę virtualioje mašinoje, kaip ir bet kurioje kitoje procesoriaus metrikoje, paprasta: galite naudoti bet kurį procesoriaus metrikos įrankį. Svarbiausia, kad virtualioji mašina būtų „Linux“. Dėl tam tikrų priežasčių „Windows“ tokios informacijos savo vartotojams neteikia. 🙁
Viršutinės komandos išvestis: išsamiai aprašoma procesoriaus apkrova, dešiniajame stulpelyje - pavogti
Sunkumai kyla bandant gauti šią informaciją iš hipervizoriaus. Galite pabandyti nuspėti vagystę pagrindiniame kompiuteryje, pavyzdžiui, pagal parametrą Load Average (LA) - vidutinę procesų, laukiančių vykdymo eilėje, skaičiaus reikšmę. Šio parametro apskaičiavimo metodas nėra paprastas, tačiau apskritai, jei LA, normalizuotas pagal procesoriaus gijų skaičių, yra didesnis nei 1, tai rodo, kad Linux serveris yra kažkuo perkrautas.
Ko laukia visi šie procesai? Akivaizdus atsakymas yra procesoriai. Tačiau atsakymas nėra visiškai teisingas, nes kartais procesorius yra laisvas, o LA nukrypsta nuo masto. Prisiminti . Maždaug tas pats gali būti su disku ir kitais įvesties / išvesties įrenginiais. Tačiau iš tikrųjų procesai gali laukti, kol baigsis bet koks užraktas, tiek fizinis, susietas su įvesties / išvesties įrenginiu, tiek loginis, pavyzdžiui, nutildymas. Tai taip pat apima užraktus aparatinės įrangos lygiu (tas pats atsakas iš disko) arba logiką (vadinamuosius užrakinimo primityvus, kurie apima daugybę objektų, mutex adaptyvų ir sukimąsi, semaforus, sąlygų kintamuosius, rw užraktus, ipc užraktus. ..).
Kita LA ypatybė yra ta, kad ji laikoma vidutine operacinės sistemos verte. Pavyzdžiui, 100 procesų varžosi dėl vieno failo, o tada LA=50. Atrodytų, tokia didelė reikšmė rodo, kad operacinė sistema yra bloga. Bet kitam kreivai parašytam kodui tai gali būti normali būsena, nepaisant to, kad tik jis blogas, o kiti procesai operacinėje sistemoje nenukenčia.
Dėl šio vidurkio (ir ne trumpesnio nei minutės) nieko nustatyti pagal LA nėra pati naudingiausia užduotis, o konkrečiais atvejais rezultatai labai neaiškūs. Jei bandysite tai išsiaiškinti, pamatysite, kad Vikipedijos straipsniuose ir kituose prieinamuose šaltiniuose aprašomi tik paprasčiausi atvejai, be išsamaus proceso paaiškinimo. Vėl siunčiu visus besidominčius - sekite nuorodas. Kas tingi angliškai - .
3. Specialieji efektai
Dabar pakalbėkime apie pagrindinius vagystės atvejus, su kuriais susidūrėme. Aš jums pasakysiu, kaip jie išplaukia iš visų aukščiau išvardytų dalykų ir kaip jie koreliuoja su hipervizoriaus rodikliais.
Perdirbimas. Paprasčiausias ir labiausiai paplitęs: hipervizorius yra perdirbamas. Iš tiesų, yra daug veikiančių virtualių mašinų, didelis procesoriaus suvartojimas jose, didelė konkurencija, LA panaudojimas didesnis nei 1 (normalizuotas procesoriaus gijomis). Viso virtualoko viduje viskas sulėtėja. Iš hipervizoriaus perduodama vagystė taip pat auga, reikia perskirstyti krūvį ar ką nors išjungti. Apskritai viskas logiška ir suprantama.
Paravirtualizacija prieš pavienius atvejus. Hipervizoriuje yra tik viena virtuali mašina, ji sunaudoja nedidelę jos dalį, bet suteikia didelę įvesties / išvesties apkrovą, pavyzdžiui, diske. Ir iš kažkur jame atsiranda maža pavogta, iki 10% (kaip rodo keli eksperimentai).
Byla įdomi. Steal čia atsiranda tik dėl užraktų paravirtualizuotų vairuotojų lygyje. Virtualioje mašinoje sukuriamas pertraukimas, apdorojamas tvarkyklės ir nukreipiamas į hipervizorių. Dėl apdorojimo pertraukimo hipervizoriuje tai atrodo kaip išsiųsta užklausa į virtualią mašiną, ji yra paruošta vykdyti ir laukia procesoriaus, tačiau jai nesuteikiamas procesoriaus laikas. Virtuali mašina mano, kad šis laikas pavogtas.
Tai atsitinka tuo metu, kai siunčiamas buferis, jis patenka į hipervizoriaus branduolio erdvę ir mes pradedame jo laukti. Nors virtualios mašinos požiūriu jis turėtų nedelsdamas grįžti. Todėl pagal vagystės skaičiavimo algoritmą šis laikas laikomas pavogtu. Greičiausiai šioje situacijoje gali būti ir kitų mechanizmų (pavyzdžiui, apdoroti dar kelis sys iškvietimus), tačiau jie neturėtų labai skirtis.
Planuoklis, skirtas labai apkrautoms virtualioms mašinoms. Kai viena virtuali mašina kenčia nuo vagystės labiau nei kitos, tai lemia būtent planuotojas. Kuo daugiau procesas apkrauna procesorių, tuo greičiau planuotojas jį pašalins, kad galėtų veikti ir kiti. Jei virtuali mašina suvartoja šiek tiek, vargu ar pamatys vagystę: jos procesas sąžiningai sėdėjo ir laukė, reikėtų skirti daugiau laiko. Jei virtuali mašina maksimaliai apkrauna visus savo branduolius, ji dažniau išspiriama iš procesoriaus ir stengiamasi neskirti jam daug laiko.
Dar blogiau, kai procesai virtualioje mašinoje bando gauti daugiau procesoriaus, nes negali susidoroti su duomenų apdorojimu. Tada hipervizoriaus operacinė sistema dėl sąžiningo optimizavimo skirs vis mažiau procesoriui laiko. Šis procesas vyksta kaip lavina ir vagystės šokinėja į dangų, nors kitos virtualios mašinos to vargu ar gali pastebėti. Ir kuo daugiau branduolių, tuo prastesnė mašina pateko į platinimą. Trumpai tariant, labiausiai nukenčia labai apkrautos virtualios mašinos su daug branduolių.
Žemas LA, bet yra vagysčių. Jei LA yra apie 0,7 (tai yra, atrodo, kad hipervizorius per mažai apkrautas), bet pavogimas pastebimas atskirose virtualiose mašinose:
- Aukščiau jau aprašyta parinktis su paravirtualizacija. Virtuali mašina gali gauti metrikas, rodančias vagystę, nors hipervizorius veikia gerai. Remiantis mūsų eksperimentų rezultatais, ši pavogimo parinktis neviršija 10% ir neturėtų turėti didelės įtakos programos veikimui virtualioje mašinoje.
- LA parametras laikomas neteisingu. Tiksliau, kiekvienu konkrečiu momentu jis laikomas teisingu, tačiau, suskaičiavus vidurkį per vieną minutę, paaiškėja, kad jis neįvertintas. Pavyzdžiui, jei viena virtuali mašina trečdaliui hipervizoriaus sunaudoja visus savo procesorius lygiai pusę minutės, tai LA per minutę hipervizoriuje bus 0,15; keturios tokios virtualios mašinos dirbdamos vienu metu duos 0,6. Ir tai, kad po pusę minutės kiekvienoje iš jų buvo laukinis pavogimas 25% LA atžvilgiu, nebegalima ištraukti.
- Vėlgi, dėl planuotojo, kuris nusprendė, kad kažkas valgo per daug, ir tegul kažkas palaukia. Tuo tarpu aš perjungsiu kontekstą, tvarkysiu pertraukimus ir pasirūpinsiu kitais svarbiais sistemos dalykais. Dėl to kai kurios virtualios mašinos nemato jokių problemų, o kitos patiria rimtą našumo pablogėjimą.
4. Kiti iškraipymai
Yra dar milijonas priežasčių, kodėl virtualioje mašinoje iškreipiamas sąžiningas procesoriaus laiko grąžinimas. Pavyzdžiui, hipergijos ir NUMA padidina skaičiavimų sudėtingumą. Jie visiškai supainioja proceso vykdymo branduolio pasirinkimą, nes planuotojas naudoja koeficientus - svorius, kurie, keičiant kontekstą, dar labiau apsunkina skaičiavimą.
Iškraipymų atsiranda dėl tokių technologijų kaip turbo boost arba, atvirkščiai, energijos taupymo režimas, kuris, skaičiuojant panaudojimą, gali dirbtinai padidinti arba sumažinti serverio dažnį ar net laiko kvantą. Turbo boost įjungimas sumažina vienos procesoriaus gijos našumą, nes padidėja kitos procesoriaus našumas. Šiuo metu informacija apie esamą procesoriaus dažnį į virtualią mašiną neperduodama ir mano, kad kažkas vagia jos laiką (pavyzdžiui, prašė 2 GHz, bet gavo perpus mažiau).
Apskritai iškraipymų priežasčių gali būti daug. Tam tikroje sistemoje galite rasti ką nors kita. Geriau pradėti nuo knygų, į kurias pateikiau nuorodas aukščiau, ir skaityti statistiką iš hipervizoriaus naudojant tokias paslaugas kaip perf, sysdig, systemtap, iš kurių .
5. Išvados
- Tam tikras pavogimas gali įvykti dėl paravirtualizacijos, ir tai gali būti laikoma normalia. Internete jie rašo, kad ši vertė gali būti 5-10%. Tai priklauso nuo programų, esančių virtualioje mašinoje, ir nuo to, kokią apkrovą ji suteikia savo fiziniams įrenginiams. Čia svarbu atkreipti dėmesį į tai, kaip programos jaučiasi virtualiose mašinose.
- Hipervizoriaus apkrovos ir vagystės santykis virtualioje mašinoje ne visada yra vienareikšmiškai tarpusavyje susijęs, abu pavogimo įverčiai gali būti klaidingi konkrečiose situacijose esant skirtingoms apkrovoms.
- Planuotojas turi blogą požiūrį į procesus, kurie reikalauja daug. Jis stengiasi mažiau duoti tiems, kurie prašo daugiau. Didelės virtualios mašinos yra blogis.
- Mažas pavogimas gali būti norma net ir be paravirtualizacijos (atsižvelgiant į apkrovą virtualioje mašinoje, kaimynų apkrovos charakteristikas, apkrovos pasiskirstymą tarp gijų ir kitus veiksnius).
- Jei norite išsiaiškinti vagystę konkrečioje sistemoje, turite ištirti įvairias galimybes, rinkti metrikas, atidžiai juos išanalizuoti ir galvoti, kaip tolygiai paskirstyti apkrovą. Galimi nukrypimai nuo bet kokių atvejų, kuriuos reikia patvirtinti eksperimentiškai arba peržiūrėti branduolio derinimo programoje.
Šaltinis: www.habr.com