Steal: tko krade procesorsko vrijeme od virtualnih mašina

Bok! Želim objasniti jednostavnim jezikom mehaniku nastanka steala unutar virtualnih mašina i neka nevidljiva obilježja koja smo otkrili tijekom istraživanja na koje sam se kao tehnička direktorica oblaka morala fokusirati. Mail.ru Cloud Solutions. Platforma radi na KVM-u.

CPU steal time — to je vrijeme u kojem virtualna mašina ne dobiva resurse procesora za svoje izvršavanje. Ovo vrijeme se računa samo u gostujućim operativnim sustavima unutar virtualizacijskih okruženja. Razlozi zbog kojih se ti dodijeljeni resursi gube su, kao i u životu, prilično magloviti. No, odlučili smo istražiti, čak smo proveli čitav niz eksperimenta. Ne kažem da sada znamo sve o stealu, ali ćemo ispričati zanimljive stvari.

1. Što je steal

Dakle, steal je metrika koja ukazuje na nedostatak procesorskog vremena za procese unutar virtualne mašine. Kao što je opisano u KVM kernel patchu, steal je vrijeme u kojem hipervizor izvršava druge procese na host operativnom sustavu, iako je proces virtualne mašine stavljen u red za izvršavanje. Drugim riječima, steal se smatra kao razlika između vremena kada je proces spreman za izvršavanje i vremena kada mu je dodijeljeno procesorsko vrijeme.

Metričku vrijednost steala kernel virtualne mašine dobiva od hipervizora. Pri tome hipervizor ne precizira koje točno druge procese izvršava, jednostavno kaže: 'Dok sam zauzet, ne mogu ti posvetiti vrijeme.' Na KVM-u, podrška za izračunavanje steala dodana je u zakrpama. Ključne točke su dvije:

• Virtualna mašina saznaje za steal od hipervizora. Drugim riječima, iz perspektive gubitaka, za procese na samoj virtualnoj mašini to je neizravno mjerenje koje može biti podložno raznim distorzijama.
• Hipervizor ne dijeli s virtualnom mašinom informacije o tome čime je drugim zauzet — važno je da joj ne posvećuje vrijeme. Zbog toga sama virtualna mašina ne može uočiti distorzije u pokazatelju steala koje bi mogle biti procijenjene prema karakteru konkurentskih procesa.

2. Što utječe na steal

2.1. Izračunavanje steala

U suštini, steal se smatra otprilike na isti način kao i redovno vrijeme iskorištenja procesora. Informacija o tome kako se računa iskorištenje nije mnogo. Vjerojatno zato što većina smatra ovo pitanje očitim. No, i ovdje postoje zamke. Za upoznavanje s ovim procesom možete pročitati članak Brendann Gregg: saznat ćete o mnogim nijansama prilikom izračuna iskorištenja i o situacijama kada će taj izračun biti pogrešan iz sljedećih razloga:

• Pregrijavanje procesora, pri čemu se propuštaju ciklusi.
• Uključivanje/isključivanje turbo boosta, kao rezultat čega se mijenja taktaška frekvencija procesora.
• Promjena trajanja kvanta vremena, koja se događa prilikom korištenja tehnologija uštede energije procesora, poput SpeedStep.
• Problem izračuna prosjeka: procjena iskorištenja tijekom jedne minute na razini 80 % može prikriti kratkotrajan porast na 100 %.
• Ciklična blokada (spin lock) uzrokuje da je procesor iskorišten, ali korisnički proces ne vidi napredak u svom izvršenju. Kao rezultat, izračunata iskorištenost procesora od strane procesa će biti sto posto, iako fizički procesorsko vrijeme proces ne može koristiti.

Nisam pronašao članak koji opisuje sličan izračun za steal (ako znate – podijelite u komentarima). No, prema izvorima, mehanizam izračuna je isti kao i za iskorištenje. Jednostavno se u jezgru dodaje još jedan brojač, izravno za proces KVM (proces virtualne mašine), koji broji trajanje boravka KVM procesa u stanju čekanja procesorskog vremena. Brojač uzima informacije o procesoru iz njegove specifikacije i provjerava jesu li svi njegovi takti iskorišteni od strane virtualnog procesa. Ako jesu, smatramo da je procesor bio angažiran samo na procesu virtualne mašine. U suprotnom, obavještavamo da je procesor bio angažiran nečim drugim, došlo je do steala.

Proces izračuna steala podložan je istim problemima kao i obični izračun iskorištenja. Ne može se reći da takvi problemi često nastaju, ali izgledaju obeshrabrujuće.

2.2. Tipovi virtualizacije na KVM

Općenito, postoje tri tipa virtualizacije, i svi su podržani od strane KVM-a. Od tipa virtualizacije može ovisiti mehanizam nastanka steala.

Prijevod. U tom slučaju rad operativnog sustava virtualne mašine s fizičkim uređajima hipervizora događa se otprilike ovako:

1. Gostujući operativni sustav šalje naredbu svom gostujućem uređaju.
2. Vozač gostujućeg uređaja prima naredbu, formira zahtjev za BIOS uređaja i šalje ga hipervizoru.
3. Proces hipervizora prevodi naredbu u naredbu za fizički uređaj, čineći je, između ostalog, sigurnijom.
4. Vozač fizičkog uređaja prima modificiranu naredbu i šalje je već u sam fizički uređaj.
5. Rezultati izvršenja naredbi vraćaju se istim putem.

Prednost prevoditeljske tehnike je u tome što omogućuje emulaciju bilo kojeg uređaja i ne zahtijeva posebnu pripremu jezgre operativnog sustava. No, za to se prvenstveno plaća brzinom.

Hardverska virtualizacija. U tom slučaju uređaj na hardverskoj razini razumije naredbe iz operativnog sustava. To je najbrži i najbolji način. No, nažalost, podržava ga daleko ne svaki fizički uređaj, hipervizor ili gostujući operativni sustav. Trenutno su glavni uređaji koji podržavaju hardversku virtualizaciju procesori.

Paravirtualizacija (paravirtualization). Najčešća varijanta virtualizacije uređaja na KVM-u i općenito najrašireniji način virtualizacije za gostujuće operativne sustave. Njegova osobina je što rad s nekim podsustavima hipervizora (na primjer, s mrežnim ili diskovnim stakom) ili dodjela stranica memorije se odvija korištenjem API-ja hipervizora, bez prevođenja nisko razinskih naredbi. Nedostatak ovog pristupa virtualizaciji je potreba za modifikacijom jezgre gostujućeg operativnog sustava, kako bi mogao komunicirati s hipervizorom putem ovog API-ja. No, to se obično rješava instalacijom posebnih vozača na gostujući operativni sustav. U KVM-u se taj API naziva virtio API.

Kod para-virtualizacije, u usporedbi s prevođenjem, put do fizičkog uređaja značajno se skraćuje slanjem naredbi iz virtualne mašine izravno u proces hipervizora na hostu. To omogućuje ubrzanje izvršavanja svih instrukcija unutar virtualne mašine. U KVM-u za to je zadužen virtio API, koji radi samo za određene uređaje, poput mrežnog ili diskovnog adaptera. Zato se unutar virtualnih mašina instaliraju virtio vozači.

S druge strane, ovo ubrzanje znači da svi procesi koji se izvode unutar virtualne mašine ne ostaju isključivo unutar nje. To stvara neke posebne efekte koji mogu dovesti do pojave na steal. Preporučujem da detaljno proučavanje ove teme započnete s API za virtualni I/O: virtio.

2.3. 'Pravedno' zakazivanje

Virtualka na hipervizoru zapravo je običan proces koji podliježe pravilima zakazivanja (distribucije resursa između procesa) u Linux jezgru, stoga ćemo je detaljnije razmotriti.

U Linuxu se koristi tzv. CFS, Completely Fair Scheduler, koji je od verzije jezgre 2.6.23 postao zadani planer. Kako biste se bolje upoznali s ovim algoritmom, možete pročitati Linux Kernel Architecture ili izvorne kodove. Suština CFS-a leži u raspodjeli procesorskog vremena između procesa u zavisnosti od trajanja njihovog izvršenja. Što više procesorskog vremena zahtijeva proces, to manje tog vremena dobija. To jamči 'pravedno' izvršavanje svih procesa — kako jedan proces ne bi konstantno zauzimao sve procesore, a ostali procesi također mogli biti izvršeni.

Ponekad ova paradigma dovodi do zanimljivih artefakata. Dugi korisnici Linux-a sigurno se sjećaju zamrzavanja običnog tekstualnog urednika na desktopu prilikom pokretanja resursno zahtjevnih aplikacija poput kompajlera. To se događalo jer su nerazmjerno zahtjevni zadaci desktop aplikacija konkurirali zadacima koji aktivno troše resurse, poput kompajlera. CFS smatra da je to nepravedno, stoga povremeno zaustavlja tekstualni urednik i omogućava procesoru da obrade zadatke kompajlera. To je ispravljeno pomoću mehanizma sched_autogroup, ali su ostale mnoge značajke raspodjele procesorskog vremena između zadataka ostale. U suštini, ovo nije priča o tome kako je sve loše u CFS-u, već pokušaj skrenuti pažnju na to da je "poštena" raspodjela procesorskog vremena – sve samo ne trivijalan zadatak.

Još jedna važna stvar u scheduleru je preempcija. To je potrebno da se nahranjeni proces izbaci s procesora i omogući drugima da rade. Proces izbacivanja zove se prebacivanje konteksta, ili context switching. Prilikom toga se čuva cijeli kontekst zadatka: stanje steka, registri i ostalo, nakon čega se proces šalje na čekanje, a na njegovo mjesto dolazi drugi. To je skupa operacija za OS, i koristi se rijetko, ali u suštini u tome nema ništa loše. Česta prebacivanja konteksta mogu ukazivati na problem u OS-u, ali obično se odvijaju neprekidno i ne ukazuju ni na što posebno.

Ova duga priča potrebna je za objašnjenje jednog fakto: što više resursa procesora pokušava potrošiti proces u poštenom scheduleru Linuxa, to će brže biti zaustavljen kako bi i drugi procesi mogli raditi. Da li je to ispravno ili ne — složeno je pitanje koje se daje različito rješava u zavisnosti od opterećenja. U Windowsima je do nedavno scheduler bio orijentiran na prioritetnu obradu desktop aplikacija, zbog čega su pozadinski procesi mogli zakazivati. U Sun Solaris-u postojalo je pet različitih klasa schedulera. Kada je pokrenuta virtualizacija, dodana je šesta. Plan raspodjele po fer načelu, budući da je prethodnih pet neadekvatno radilo s virtualizacijom Solaris Zones. Preporučujem da detaljno proučite ovo pitanje počevši od knjiga poput Solaris Internals: Solaris 10 i OpenSolaris Kernel Architecture ili Understanding the Linux Kernel.

2.4. Kako pratiti steal?

Praćenje steala unutar virtualne mašine, kao i bilo koje druge procesorske metrike, jednostavno je: možete koristiti bilo koji alat za prikupljanje metrika procesora. Najvažnije je da virtualka bude na Linuxu. Windows iz nekog razloga ne pruža takve informacije svojim korisnicima. 🙁

Izlaz komande top: detaljizacija opterećenja procesora, u ekstremnoj desnoj koloni — steal

Poteškoće se javljaju prilikom pokušaja dobivanja ovih informacija s hipervizora. Možete pokušati predvidjeti steal na host mašini, na primjer, prema parametru Load Average (LA) — prosječne vrijednosti broja procesa koji čekaju u redu za izvršenje. Metodologija izračunavanja ovog parametra nije jednostavna, ali općenito, ako je normalizirani LA po broju CPU niti veći od 1, to ukazuje da je server s Linuxom nečim preopterećen.

Čega se svi ti procesi zapravo čekaju? Očigledan odgovor je — procesora. No, odgovor nije potpuno tačan, jer ponekad je procesor slobodan, a LA se povišava. Sjetite se, kako NFS pada i pri tome raste LA. Otprilike tako može biti i s diskom, i s drugim uređajima za ulaz/izlaz. No zapravo, procesi mogu čekati završetak bilo koje blokade, bilo fizičke, povezane s uređajem za ulaz/izlaz, ili logičke, poput mutexa. Tamo spadaju blokade na razini hardvera (isto odgovora s diska) ili logike (tzv. blokadne primitive, koje uključuju mnoštvo entiteta, adaptivni mutex i spin, semafore, uvjetne varijable, rw zaključavanja, ipc zaključavanja…).

Još jedna osobina LA je ta da se ona računa kao prosječna vrijednost kroz operacijski sustav. Na primjer, 100 procesa konkurira za jednu datoteku, i tada LA=50. Ova velika vrijednost, čini se, ukazuje da operativnom sustavu nije dobro. Međutim, za neki krivo napisan kod to može biti normalno stanje, dok je loše samo njemu, a drugi procesi u operativnom sustavu ne pate.

Zbog ovog prosjeka (naime ne manje od jedne minute), definiranje bilo čega na temelju pokazatelja LA — nije najzahvalniji zadatak, s prilično neizvjesnim rezultatima u konkretnim slučajevima. Ako pokušate dokučiti, otkrit ćete da su u člancima na Wikipediji i drugim dostupnim resursima opisani samo najjednostavniji slučajevi, bez dubokog objašnjenja procesa. Sve zainteresirane opet šaljem, ovdje, Brendannu Greggu  — dalje putem poveznica. Tko se ne želi mučiti s engleskim — prijevod njegove popularne članka o LA.

3. Spektakularni efekti

Sada ćemo se fokusirati na glavne slučajeve pojave steala, s kojima smo se susretali. Ispričat ću kako proistječu iz svega prethodno rečenog i kako se odnose na pokazatelje na hipervizoru.

Pereutilizacija. Najjednostavnije i najčešće: hipervizor prelazi na ponovno korištenje. Naime, postoji mnogo pokrenutih virtualnih mašina, visoka potrošnja CPU unutar njih, velika konkurencija, iskorištenje prema LA veće od 1 (u normalizaciji prema procesorskim nitima). Unutar svih virtualnih mašina sve usporava. Steal, koji se prenosi s hipervizora, također raste, treba raspodijeliti opterećenje ili nekoga isključiti. Ukratko, sve je logično i razumljivo.

Paravirtualizacija protiv usamljenih instanci. Na hipervizoru postoji samo jedna virtualna mašina, koja troši mali dio, ali generira veliko opterećenje po unosu/izlazu, na primjer po disku. I odnekud u njoj se pojavljuje mali steal, do 10% (kako su pokazali neki provedeni eksperimenti).

Zanimljiv slučaj. Steal se ovdje pojavljuje upravo zbog blokada na razini paravirtualiziranih drajvera. Unutar virtualne mašine dolazi do prekida, koji obrađuje drajver i šalje ga do hipervizora. Zbog obrade prekida na hipervizoru za virtualnu mašinu to izgleda kao poslan zahtjev, ona je spremna za izvršenje i čeka procesor, ali joj ne daju procesorskog vremena. Virtualna mašina misli da je to vrijeme ukradeno.

To se događa u trenutku slanja bafera, on odlazi u kernel prostor hipervizora, i počinjemo ga čekati. Iako, s gledišta virtualne mašine, on bi trebao odmah da se vrati. Stoga, prema algoritmu izračuna steal, to vrijeme se smatra ukradenim. Vjerojatno se u ovoj situaciji mogu dogoditi i drugi mehanizmi (na primjer, obrada još nekih sys calls), ali oni se ne bi trebali jako razlikovati.

Scheduler protiv visoko opterećenih virtualnih mašina. Kada jedna virtualna mašina pati od steal više od drugih, to je povezano upravo sa schedulerom. Što više proces opterećuje procesor, to ga scheduler brže isključuje kako bi i ostali mogli raditi. Ako virtualna mašina troši malo, gotovo neće primijetiti steal: njen proces pravedno sjedi i čeka, treba joj dati više vremena. Ako virtualna mašina proizvodi maksimalno opterećenje kroz sve svoje jezgre, češće je isključuju s procesora i trude se ne davati joj puno vremena.

Još je gore kada procesi unutar virtualne mašine pokušavaju dobiti više procesorskog vremena jer ne mogu obraditi podatke. Tada operativni sistem na hipervizoru, zahvaljujući poštenoj optimizaciji, daje sve manje procesorskog vremena. Ovaj proces se odvija lavinom, a steal skače do neba, iako ga ostale virtualke gotovo i ne primjećuju. A što je više jezgri, to je gore za mašinu koja je zahvaćena. Ukratko, najviše pate visoko opterećene virtualke sa mnogo jezgri.

Nizak LA, ali ima steal. Ako je LA otprilike 0,7 (tj. hipervizor se čini nedovoljno opterećenim), ali unutar pojedinih virtualnih mašina se primjećuje steal:

• Već opisani scenarij s paravirtualizacijom. Virtualka može dobiti metrike koje ukazuju na steal, iako je sve u hipervizoru u redu. Prema rezultatima naših eksperimenata, takav steal ne prelazi 10 % i ne bi trebao značajno utjecati na performanse aplikacija unutar virtualke.
• Pogrešno se računa parametar LA. Preciznije, u svakom konkretnom trenutku se računa ispravno, ali prosjek za jednu minutu ispadne podcijenjen. Na primjer, ako jedna virtualka na trećini hipervizora troši sve svoje procese točno pola minute, LA za minutu na hipervizoru će biti 0,15; četiri takve virtualke koje rade istovremeno daju 0,6. A to što je na svakoj od njih pola minute bio ogroman steal od 25 % prema LA, više se ne može izvući.
• Opet, zbog šedulera, koji je odlučio da netko previše troši, pa neka taj netko čeka. A ja ću prebacivati kontekst, obrađivati prekide i baviti se drugim važnim sistemskim stvarima. Na kraju, jedne virtualke ne vide nikakve probleme, dok druge doživljavaju ozbiljno pogoršanje performansi.

4. Druga izobličenja

Postoji još milion razloga za izobličenja poštene isporuke procesorskog vremena na virtualnoj mašini. Na primjer, poteškoće u proračunima unose hyper-threading i NUMA. Oni konačno zbunjuju izbor jezgre za izvršavanje procesa, jer šeduler koristi koeficijente — težine, koje prilikom prebacivanja konteksta čine izračun još složenijim.

Mogući su distorzije zbog tehnologija poput turbo boosta ili, s druge strane, načina uštede energije, koji mogu umjetno povećavati ili smanjivati frekvenciju ili čak kvant vremena na serveru prilikom izračuna iskorištenosti. Aktiviranje turbo boosta smanjuje performanse jednog procesora zbog povećanja performansi drugog. U tom trenutku informacija o trenutnoj frekvenciji procesora ne dolazi do virtualnog stroja, a on misli da mu netko krade vrijeme (na primjer, zatražio je 2 GHz, a dobio je upola manje).

Općenito, može biti mnogo uzroka distorzija. U specifičnom sustavu možete otkriti nešto drugo. Bolje je početi s knjigama na koje sam dao linkove iznad i snimanjem statistike s hipervizora pomoću alata poput perf, sysdig, systemtap, kojih ima desetaka.

5. Zaključci

1. Neki iznos steal-a može se javiti zbog para-virtualizacije i može se smatrati normalnim. Na internetu se piše da bi ta veličina mogla iznositi 5-10%. Ovisi o aplikacijama unutar virtualnog stroja i o opterećenju koje stvara na svojim fizičkim uređajima. Ovdje je važno obratiti pozornost na to kako se osjećaju aplikacije unutar virtualnih strojeva.
2. Omjer opterećenja na hipervizoru i steal unutar virtualnog stroja nije uvijek jednoznačno povezan, te mogu biti pogrešne procjene steal-a u određenim situacijama s različitim opterećenjima.
3. Scheduler se loše odnosi prema procesima koji mnogo traže. Pokušava dati manje onima koji traže više. Velike virtualke su zlo.
4. Mali steal može biti norma i bez para-virtualizacije (uzimajući u obzir opterećenje unutar virtualnog stroja, posebnosti opterećenja susjeda, raspodjelu opterećenja po nitima i druge faktore).
5. Ako želite utvrditi steal u specifičnom sustavu, morate istražiti različite opcije, prikupljati metrike, temeljito ih analizirati i razmisliti o načinu ravnomjerne raspodjele opterećenja. Od svih slučajeva moguće su odredbe koje treba potvrditi eksperimentalno ili pregledavati u debageru jezgre.

Izvor: habr.com