Ahoj! Chcem jednoducho vysvetliť mechaniku vzniku steal v rámci virtuálnych strojov a niektoré menej zjavné artefakty, ktoré sme dokázali objasniť počas jeho skúmania, do ktorého som sa musel ponoriť ako technický riaditeľ cloudovej platformy. . Platforma funguje na KVM.
CPU steal time je čas, počas ktorého virtuálny stroj nedostáva procesorové zdroje na svoje vykonávanie. Tento čas sa počíta iba v hostiteľských operačných systémoch v prostrediach virtualizácie. Dôvody, kam sa tieto vyčlenené zdroje strácajú, sú, podobne ako v živote, dosť nejasné. Ale rozhodli sme sa to preskúmať, dokonca sme vykonali celú sériu experimentov. Nie že by sme teraz všetko vedeli o steal, ale niečo zaujímavé vám teraz povieme.
1. Čo je steal
Takže steal je metrika, ktorá naznačuje nedostatok procesorového času pre procesy vo vnútri virtuálneho stroja. Ako je popísané , steal je čas, počas ktorého hypervízor vykonáva iné procesy na hostiteľskom OS, hoci dal proces virtuálneho stroja do poradia na vykonanie. To znamená, že steal sa počíta ako rozdiel medzi časom, keď je proces pripravený na vykonanie, a časom, kedy mu je pridelený procesorový čas.
Metriku steal jadro virtuálneho stroja získava od hypervízora. Pri tom hypervízor nešpecifikuje, aké presne iné procesy vykonáva, jednoducho "kým som zamestnaný, nemôžem ti venovať čas". Na KVM bola podpora počítania steal pridaná v Dva kľúčové body sú tu:
- Virtuálny stroj získava informácie o steal od hypervízora. To znamená, že z pohľadu strát je to pre procesy na samotnom virtuálnom stroji nepriamy ukazovateľ, ktorý môže byť vystavený rôznym skresleniam.
- Hypervízor sa nezdieľa s virtuálnym strojom informáciou o tom, čím iným je zamestnaný – dôležité je, že mu nevenuje čas. Z tohto dôvodu samotný virtuálny stroj nemôže identifikovať skreslenia v ukazovateli steal, ktoré by mohli byť posúdené podľa charakteru konkurenčných procesov.
2. Čo ovplyvňuje steal
2.1. Výpočet steal
V podstate sa steal počíta približne rovnako, ako obvyklý čas využitia procesora. Informácií o tom, ako sa počíta využitie, nie je veľa. Pravdepodobne preto, že väčšina považuje túto otázku za zrejmú. Ale aj tu môžu byť nejaké úskalia. Pre oboznámenie sa s týmto procesom si môžete prečítať. : dozviete sa o množstve nuáns pri výpočte využitia a o situáciách, kedy bude tento výpočet chybný z týchto dôvodov:
- Prehriatie procesora, pri ktorom sa preskakuje takty.
- Zapínanie/vypínanie turbo boostu, v dôsledku ktorého sa mení taktovacia frekvencia procesora.
- Zmena trvania časového kvanta, k čomu dochádza pri využívaní technológií šetrenia energie procesora, napríklad SpeedStep.
- Problém pri výpočte priemeru: odhad využitia počas jednej minúty na úrovni 80 % môže skryť krátkodobý výbuch na úrovni 100 %.
- Cyklické zamknutie (spin lock) vedie k tomu, že procesor je využitý, ale používateľský proces nevidí pokrok vo svojom vykonávaní. V dôsledku toho sa odhadovaná využiteľnosť procesora procesom zobrazuje ako stopercentná, hoci fyzicky procesorový čas proces spotrebúvať nebude.
Články opisujúce podobný výpočet pre steal som nenašiel (ak viete — podeľte sa v komentároch). Ale podľa zdrojových dokumentov je mechanizmus výpočtu rovnaký ako pre využitie. Do jadra sa jednoducho pridá ďalší čítač priamo pre proces KVM (proces virtuálnej mašiny), ktorý počíta dĺžku pobytu procesu KVM v stave čakania na procesový čas. Čítač berie informácie o procesore zo špecifikácie a sleduje, či sú všetky jeho tiky využité procesom virtuálky. Ak áno, považujeme, že procesor pracoval len s procesom virtuálnej mašiny. Inak informujeme, že procesor sa zaoberal niečím iným, došlo k steal.
Proces výpočtu steal je vystavený tým istým problémom, ako je bežný výpočet využitia. Nedá sa povedať, že by sa takéto problémy vyskytovali často, ale vyzerajú deprimujúco.
2.2. Typy virtualizácie na KVM
Vo všeobecnosti existujú tri typy virtualizácie, a všetky sú podporované KVM. Typ virtualizácie môže ovplyvniť mechanizmus vzniku steal.
Preklad. V tomto prípade je práca operačného systému virtuálnej mašiny s fyzickými zariadeniami hypervízora zhruba takáto:
- Hostiteľský operačný systém posiela svojmu hosťovskému zariadeniu príkaz.
- Ovládač hosťovského zariadenia prijíma príkaz, formuje požiadavku pre BIOS zariadenia a posiela ju do hypervízora.
- Hypervízor vykonáva preklad príkazu na príkaz pre fyzické zariadenie, čím sa robí aj bezpečnejším.
- Ovládač fyzického zariadenia prijíma modifikovaný príkaz a posiela ho priamo do fyzického zariadenia.
- Výsledky vykonávania príkazov sa vracajú rovnakou cestou.
Výhodou prekladu je, že umožňuje emulovať akékoľvek zariadenie a nevyžaduje špeciálnu prípravu jadra operačného systému. Musíme však za to zaplatiť, predovšetkým výkonnosťou.
Hardvérová virtualizácia. V tomto prípade zariadenie na hardvérovej úrovni rozumie príkazom z operačného systému. Je to najrýchlejší a najlepší spôsob. Bohužiaľ, nie všetky fyzické zariadenia, hypervízory a hostiteľské operačné systémy ho podporujú. V súčasnosti sú hlavné zariadenia, ktoré podporujú hardvérovú virtualizáciu, procesory.
Paravirtualizácia (paravirtualization). Najrozšírenejšia varianta virtualizácie zariadení na KVM a vôbec najbežnejší režim virtualizácie pre hosťujúce operačné systémy. Jej zvláštnosťou je, že práca s niektorými subsystémami hypervízora (napríklad sieťovým alebo diskovým systémom) alebo prideľovanie stránok pamäte sa uskutočňuje použitím API hypervízora bez prekladu nízkoúrovňových príkazov. Nevýhodou tohto spôsobu virtualizácie je potreba modifikácie jadra hosťujúceho operačného systému, aby mohlo komunikovať s hypervízorom cez toto API. Zvyčajne sa to však rieši inštaláciou špeciálnych ovládačov do hosťujúceho operačného systému. V KVM sa toto API nazýva .
Pri paravirtualizácii, v porovnaní s prekladom, sa cesta k fyzickému zariadeniu značně skracuje vďaka priamemu odoslaniu príkazov z virtuálneho stroja do procesu hypervízora na hostiteľskom systéme. To umožňuje urýchliť vykonávanie všetkých inštrukcií vo vnútri virtuálneho stroja. V KVM za to zodpovedá virtio API, ktoré funguje len pre určité zariadenia, ako sú sieťové alebo diskové adaptéry. Práve preto sa do virtuálnych strojov inštalujú ovládače virtio.
Negatívna stránka takéhoto zrýchlenia je, že nie všetky procesy, ktoré sa vykonávajú vo virtuálnom stroji, zostávajú vo vnútri neho. To vytvára niektoré špeciálne efekty, ktoré môžu viesť k objaveniu na steal. Odporúčam podrobne preskúmať túto problematiku začínajúc od .
2.3. „Spravodlivé“ plánovanie
Virtuálny stroj na hypervízore je v podstate obyčajný proces, ktorý podlieha zákonom plánovania (rozdeľovania zdrojov medzi procesmi) v jadre Linuxu, preto sa na to pozrime podrobnejšie.
V Linuxe sa používa takzvaný CFS, Completely Fair Scheduler, ktorý sa stal predvoleným plánovačom od jadra 2.6.23. Aby ste pochopili tento algoritmus, môžete si prečítať Linux Kernel Architecture alebo zdrojový kód. Podstata CFS spočíva v rozdeľovaní procesorového času medzi procesmi v závislosti od dĺžky ich vykonávania. Čím viac procesorového času proces potrebuje, tým menej tohto času dostáva. To garantuje „spravodlivé“ vykonávanie všetkých procesov — aby jeden proces neobsadil všetky procesory neustále a ostatné procesy mohli tiež vykonávať.
Niekedy táto paradigma vedie k zaujímavým artefaktom. Dlhodobí používatelia Linuxu si určite pamätajú zamŕzanie obyčajného textového editora na desktopoch pri spustení náročných aplikácií ako je kompilátor. Stávalo sa to preto, lebo nerazovo náročné úlohy desktopových aplikácií súťažili s úlohami, ktoré aktívne spotrebúvajú prostriedky, ako je kompilátor. CFS považuje toto za nespravodlivé, preto občas zastaví textový editor a nechá procesor spracovať úlohy kompilátora. To sa opravilo pomocou mechanizmu , ale zostali mnohé ďalšie vlastnosti rozdeľovania procesorového času medzi úlohami. Vlastne, toto nie je rozprávanie o tom, ako to všetko zle funguje v CFS, ale pokus upozorniť na to, že „spravodlivé“ rozdeľovanie procesorového času nie je triviálna úloha.
Ďalší dôležitý aspekt v plánovači je preemption. Je to potrebné na to, aby sa odstránil „prežratý“ proces z procesora a dal priestor iným. Proces odstránenia sa nazýva prepínanie kontextu procesora. Pri tom sa zachováva celý kontext úlohy: stav zásobníka, registre a ďalšie, po čom je proces poslaný na čakanie a na jeho miesto nastupuje iný. Je to nákladná operácia pre operačný systém, a používa sa zriedkavo, ale v podstate na tom nie je nič zlé. Časté prepínanie kontextu môže naznačovať problém v operačnom systéme, ale zvyčajne prebieha nepretržite a na niečo špeciálne neukazuje.
Tento dlhý príbeh je potrebný na vysvetlenie jedného faktu: čím viac zdrojov procesora sa snaží spotrebovať proces v férovom plánovači Linuxu, tým rýchlejšie bude zastavený, aby mohli pracovať aj iné procesy. Či je to správne alebo nie, je zložitá otázka, ktorá sa pri rôznych zaťaženiach rieši rôzne. V systéme Windows bol doteraz plánovač orientovaný na prioritnú obranu desktopových aplikácií, čo mohlo spôsobovať zamrznutie pozadí procesov. V Sun Solaris existovalo päť rôznych tried plánovačov. Keď zaviedli virtualizáciu, pridali šiesty, , pretože predchádzajúcich päť pracovalo s virtualizáciou Solaris Zones neadekvátne. Podrobné štúdium tejto problematiky odporúčam začať knihami ako sú alebo .
2.4. Ako monitorovať steal?
Monitorovanie steal v rámci virtuálneho stroja, ako aj akúkoľvek inú procesorovú metriku, je jednoduché: môžete používať akýkoľvek nástroj na meranie procesorových metrík. Hlavné je, aby virtuálka bola na Linuxe. Windows z nejakého dôvodu takúto informáciu svojim používateľom neposkytuje. 🙁
Výstup príkazu top: detail loading na procesor, v najpravejšom stĺpci — steal
Sťažnosti nastávajú pri pokuse získať tieto informácie z hypervízora. Môžete sa pokúsiť predpovedať steal na hostiteľskom stroji, napríklad podľa parametra Load Average (LA) — priemernú hodnotu počtu procesov, ktoré čakajú v rade na vykonanie. Metódika počítania tohto parametra nie je jednoduchá, ale vo všeobecnosti, ak je normalizovaný podľa počtu vlákien procesora LA väčší ako 1, naznačuje to, že server s Linuxom je niečím preťažený.
Na čo všetci títo procesy čakajú? Očividná odpoveď je procesor. Ale odpoveď nie je úplne správna, pretože niekedy je procesor voľný, zatiaľ čo LA sa zvyšuje. Spomeňte si, Podobne to môže byť aj s diskom a inými vstupno/výstupnými zariadeniami. V skutočnosti môžu procesy čakať na ukončenie akéhokoľvek zámku, či už fyzického, súvisiaceho so vstupno/výstupným zariadením, alebo logického, ako napríklad mutex. Sem patrí aj zámky na úrovni hardvéru (ten istý výkon od disku) alebo logiky (tzv. zámkové primitívy, medzi ktoré patrí množstvo entít, ako sú adaptive a spin mutexy, semafory, podmienkové premenné, rw locks, ipc locks…).
Ďalšou vlastnosťou LA je, že sa počíta ako priemer cez operačný systém. Napríklad, 100 procesov súťaží o jeden súbor, a potom LA=50. Tak vysoká hodnota sa zdá naznačovať, že operačný systém má problémy. Ale pri nejakom zle napísanom kóde to môže byť normálny stav, kde je zle len jemu, zatiaľ čo ostatné procesy v operačnom systéme netrpia.
Ak ste si toho vedomí, vďaka tomu priemerovaniu (a trvá to aspoň minútu), určiť niečo na základe ukazovateľa LA — nie je vďačná úloha, s veľmi nejasnými výsledkami v konkrétnych prípadoch. Ak sa pokúsite prísť na to, zistíte, že v článkoch na Wikipédii a iných dostupných zdrojoch sú opísané iba najjednoduchšie prípady, bez hlbokého vysvetlenia procesu. Všetkých záujemcov opäť posielam — ďalej cez odkazy. Kto sa nechce trápiť s angličtinou — .
3. Špeciálne efekty
Teraz sa zastavíme pri hlavných prípadoch vzniku steal, ktorým sme sa stretli. Povieme si, ako vyplývajú z vyššie uvedeného a ako súvisia s ukazovateľmi na hypervízore.
Preutilizácia. Najjednoduchší a najbežnejší: hypervízor je preutilizovaný. Skutočne, veľa spustených virtuálnych strojov, vysoká spotreba procesora v nich, veľká konkurencia, využívanie pri LA je vyššie ako 1 (v normalizácii podľa procesorových vlákien). Vo všetkých virtuálnych strojoch je všetko spomalené. Steal, ktorý je prenášaný z hypervízora, tiež rastie, je potrebné rozložiť záťaž alebo niekoho vypnúť. Všeobecne, všetko je logické a jasné.
Paravirtualizácia proti osamelým inštanciám. Na hypervízore je len jedna virtuálka, ktorá spotrebuje malú časť jeho zdrojov, ale vytvára veľkú záťaž v oblasti vstupu/výstupu, napríklad na disku. A niekde sa v nej objaví malý steal, až do 10 % (ako ukazuje niekoľko vykonaných experimentov).
Zaujímavý prípad. Steal sa v tomto prípade objavuje práve kvôli blokovaniam na úrovni paravirtualizovaných ovládačov. Vo virtuálke sa vytvorí prerušenie, ktoré spracuje ovládač a pošle ho do hypervízora. Kvôli spracovaniu prerušenia na hypervízore to pre virtuálku vyzerá ako odoslaný požiadavok, je pripravená na vykonanie a čaká na procesor, ale procesorový čas jej nie je poskytnutý. Virtuálka si myslí, že tento čas bol ukradnutý.
To sa deje v okamihu odoslania bufferu, ktorý prejde do kernel space hypervízora, a začíname ho čakať. Hoci, z pohľadu virtuálky, by sa mal vrátiť hneď. Podľa algoritmu výpočtu steal sa tento čas považuje za ukradnutý. Pravdepodobne môžu v tejto situácii existovať aj iné mechanizmy (napríklad spracovanie ešte nejakých sys calls), ale nemali by sa výrazne líšiť.
Scheduler proti vysoko zaťaženým virtuálkam. Keď jedna virtuálka trpí stealom viac ako ostatné, je to práve kvôli scheduleru. Čím viac proces zaťažuje procesor, tým skôr ho scheduler vyhodí, aby aj ostatní mohli pracovať. Ak virtuálka spotrebuje málo, takmer si nevšimne steal: jej proces poctivo sedel a čakal, je potrebné mu dať viac času. Ak virtuálka zažíva maximálnu záťaž na všetkých svojich jadrách, častejšie ju vyháňajú z procesora a snažia sa jej nezveriť veľa času.
Ešte horšie je, keď procesy vo virtuálke sa snažia získať viac procesora, pretože nezvládajú spracovanie dát. V tom prípade operačný systém na hypervízore, vďaka poctivej optimalizácii, dáva čoraz menej procesorového času. Tento proces prebieha lavínovo a steal vyskočí do nebies, hoci ostatné virtuálky to takmer ani nezaznamenajú. A čím viac jadier, tým horšie pre stroj, ktorý sa dostane pod tlač. Skrátka, najviac trpia vysoko zaťažené virtuálky s množstvom jadier.
Nízky LA, ale je tu steal. Ak je LA približne 0,7 (to znamená, že hypervízor sa zdá byť nedostatočne zaťažený), ale vo vnútri jednotlivých virtuálok sa pozoruje steal:
- Už popísaná vyššia varianta s paravirtualizáciou. Virtuálka môže získať metriky, ktoré ukazujú na steal, aj keď hypervízor je v poriadku. Podľa výsledkov našich experimentov takýto steal nepresahuje 10 % a nemal by mať významný vplyv na výkon aplikácií vo virtuálke.
- Nesprávne sa posudzuje parameter LA. Presnejšie, v každý konkrétny okamih sa posudzuje správne, ale pri priemere za jednu minútu je výsledok podhodnotený. Napríklad, ak jedna virtuálka na tretine hypervízora využíva všetky svoje procesory presne pol minúty, LA za minútu na hypervízore bude 0,15; štyri takéto virtuálky, ktoré pracujú súčasne, dajú 0,6. A to, že pol minúty na každej z nich bol obrovský steal takmer 25 % podľa ukazovateľa LA, už nevytiahne.
- Opäť, kvôli plánovaču, ktorý usúdil, že niekto je príliš náročný a mal by chvíľu čakať. A ja zatiaľ prepínam kontext, spracovávam prerušenia a venujem sa iným dôležitým systémovým záležitostiam. Výsledkom je, že niektoré virtuálky nevidia žiadne problémy, zatiaľ čo iné zažívajú vážne zhoršenie výkonu.
4. Iné skreslenia
Existuje ešte milión dôvodov na skreslenia spravodlivej odovzdávky procesorového času na virtuálke. Napríklad, komplikácie vo výpočtoch zavádzajú hyperthreading a NUMA. Tie úplne zamotávajú výber jadra pre vykonávanie procesu, pretože plánovač používa koeficienty — váhy, ktoré pri prepínaní kontextu robia výpočet ešte zložitejším.
Môžu byť skreslenia spôsobené technológiami ako turbo boost alebo, naopak, režimy úspory energie, ktoré pri výpočte vyťaženia môžu umelo zvyšovať alebo znižovať frekvenciu, alebo dokonca kvant času na serveri. Aktivácia turbo boostu znižuje výkon jedného procesorového vlákna kvôli zvýšeniu výkonu iného. V tom okamihu informácia o aktuálnej frekvencii procesora nie je virtuálnej mašine prenášaná, a ona si myslí, že jej čas niekto kradne (napríklad žiadala 2 GHz, ale dostala dvakrát menej).
Vo všeobecnosti môže byť príčin skreslenia veľa. V konkrétnom systéme môžete objaviť niečo ďalšie. Najlepšie je začať s knihami, na ktoré som odkazoval vyššie, a zberom štatistík z hypervízora pomocou utilít ako perf, sysdig, systemtap, ktorých je .
5. Záver
- Určité množstvo steal môže vzniknúť v dôsledku paravirtualizácie a môže sa považovať za normálne. Na internete sa píše, že táto hodnota môže dosiahnuť 5-10 %. Závisí to od aplikácií vo virtuálke a od toho, akú záťaž vytvára na svoje fyzické zariadenia. Dôležité je sledovať, ako sa aplikácie vo virtuálkach cítia.
- Vzťah záťaže na hypervízore a steal vo virtuálke nie je vždy jednoznačne prepojený, obe hodnotenia steal môžu byť v konkrétnych situáciách pri rôznych záťažiach chybné.
- Šeduler nepriaznivo reaguje na procesy, ktoré veľa žiadajú. Snaží sa dávať menej tým, ktorí žiadajú viac. Veľké virtuálky sú zlo.
- Malý steal môže byť normou aj bez paravirtualizácie (s ohľadom na záťaž vo virtuálke, špecifiká záťaží susedov, rozloženie záťaže podľa vlákien a ďalšie faktory).
- Ak chcete zistiť steal v konkrétnom systéme, musíte preskúmať rôzne možnosti, zbierať metriky, dôkladne ich analyzovať a premýšľať, ako rovnomerne rozložiť záťaž. Od akýchkoľvek prípadov môžu vzniknúť odchýlky, ktoré treba potvrdiť experimentálne alebo sledovať v debagéri jadra.
Zdroj: habr.com
