Steal: chì robba u tempu di CPU da e macchine virtuali

Bonghjornu! Vogliu dì à voi in termini simplici nantu à a meccanica di arrubà in e macchine virtuali è di qualchi artefatti micca evidenti chì avemu riesciutu à scopre durante a so ricerca, chì aghju avutu à tuffarse cum'è direttore tecnicu di una piattaforma nuvola. Mail.ru Soluzioni Cloud. A piattaforma funziona nantu à KVM.

CPU steal time hè u tempu durante u quale a macchina virtuale ùn riceve risorse di processore per a so esecuzione. Stu tempu hè cuntatu solu in sistemi operativi invitati in ambienti di virtualizazione. I mutivi per induve vanu sti risorse più allocate, cum'è in a vita, sò assai vagi. Ma avemu decisu di scopre, è ancu realizatu una quantità di esperimenti. Ùn hè micca chì avà sapemu tuttu nantu à a robba, ma vi diceremu qualcosa interessante avà.

1. Chì hè arrubbatu

Dunque, steal hè una metrica chì indica una mancanza di tempu di processore per i prucessi in una macchina virtuale. Cum'è descrittu in u patch di u kernel KVMStealth hè u tempu durante u quale l'ipervisore eseguisce altri prucessi nantu à u SO di l'ospiti ancu s'ellu hà in fila u prucessu di a macchina virtuale per l'esekzione. Vale à dì, steal hè calculatu cum'è a diffarenza trà u tempu quandu u prucessu hè prontu à eseguisce è u tempu quandu u prucessu hè attribuitu u tempu di processore.

U kernel di a macchina virtuale riceve a metrica di robba da l'ipervisore. À u listessu tempu, l'ipervisore ùn specifica micca esattamente ciò chì altri prucessi hè in esecuzione, dice solu "mentre sò occupatu, ùn possu micca dà tempu". Nantu à KVM, u supportu per u calculu di robba hè statu aghjuntu patchs. Ci sò dui punti chjave quì:

• A macchina virtuale ampara nantu à arrubà da l'ipervisore. Questu hè, da u puntu di vista di perdite, per i prucessi nantu à a macchina virtuale stessu hè una misurazione indiretta chì pò esse sottumessa à diverse distorsioni.
• L'ipervisore ùn sparte micca infurmazione cù a macchina virtuale nantu à ciò chì face - u principale hè chì ùn dedicà micca u tempu. Per via di questu, a macchina virtuale stessu ùn pò micca detectà distorsioni in l'indicatore di furtu, chì puderia esse valutatu da a natura di i prucessi cuncurrenti.

2. Ciò chì tocca a robba

2.1. Arrubba u calculu

Essenzialmente, steal hè calculatu apprussimatamente u stessu tempu di usu di CPU normale. Ùn ci hè micca assai infurmazione nantu à cumu u riciclamentu hè cunsideratu. Probabilmente perchè a maiò parte di a ghjente cunsidereghja sta quistione ovvia. Ma quì ci sò ancu trappule. Per familiarizà cù stu prucessu, pudete leghje articulu di Brendan Gregg: amparate assai sfumature in u calculu di l'utilizazione è nantu à situazioni quandu stu calculu serà sbagliatu per i seguenti motivi:

• U processatore surriscalda, facennu i ciculi per saltà.
• Abilita / disattiveghja u turbo boost, chì cambia a frequenza di u clock di u processore.
• Un cambiamentu in a durata di a fetta di tempu chì si trova quandu si usa tecnulugii di risparmiu di energia di processore cum'è SpeedStep.
• U prublema cù u calculu di a media: l'estimazione di l'utilizazione di un minutu à 80% pò ammuccià un burst à cortu termini di 100%.
• Un spin lock face chì u processatore sia ricuperatu, ma u prucessu di l'utilizatori ùn vede nisun prugressu in a so esecuzione. In u risultatu, l'utilizazione di u processatore calculata da u prucessu serà centu per centu, ancu s'è u prucessu ùn cunsumerà fisicamente u tempu di processatore.

Ùn aghju micca truvatu un articulu chì descrive un calculu simili per arrubbari (se sapete, sparte in i cumenti). Ma, à ghjudicà da u codice fonte, u mecanismu di calculu hè u stessu per u riciclamentu. Simply, un altru contatore hè aghjuntu in u kernel, direttamente per u prucessu KVM (processu di macchina virtuale), chì conta a durata di u prucessu KVM chì aspetta u tempu di CPU. U cuntatore piglia infurmazione nantu à u processatore da a so specificazione è verifica se tutti i so ticks sò utilizati da u prucessu di a macchina virtuale. S'ellu hè tuttu, allora assumemu chì u processatore era occupatu solu cù u prucessu di a macchina virtuale. Altrimenti, avemu infurmatu chì u processatore facia qualcosa d'altru, steal apparsu.

U prucessu di cunti di robba hè sottumessu à i stessi prublemi cum'è u conte di riciclamentu regulare. Per ùn dì chì tali prublemi appariscenu spessu, ma parenu scoraggianti.

2.2. Tipi di virtualizazione in KVM

In generale, ci sò trè tippi di virtualizazione, chì sò tutti supportati da KVM. U mecanismu di l'occurrenza di arrubbata pò dipende da u tipu di virtualizazione.

Trasmissione. In questu casu, u funziunamentu di u sistema operatore di a macchina virtuale cù i dispositi ipervisori fisici si trova qualcosa cusì:

1. U sistema operatore invitatu manda un cumandamentu à u so dispositivu invitatu.
2. U driver di u dispositivu invitatu riceve u cumandimu, genera una dumanda per u BIOS di u dispositivu è u manda à l'hypervisor.
3. U prucessu di ipervisore traduce u cumandamentu à u cumandamentu per u dispusitivu fisicu, facendu, frà altri cose, più sicuru.
4. U driver di u dispositivu fisicu accetta u cumandamentu mudificatu è u manda à u dispusitivu fisicu stessu.
5. I risultati di eseguisce cumandamenti tornanu nantu à a stessa strada.

U vantaghju di a traduzzione hè chì permette di emulà qualsiasi dispositivu è ùn hà micca bisognu di preparazione speciale di u kernel di u sistema operatore. Ma avete da pagà per questu, prima di tuttu, in rapidità.

Virtualizazione di hardware. In questu casu, u dispusitivu à u nivellu di hardware capisce i cumandamenti da u sistema operatore. Questu hè u modu più veloce è megliu. Ma, sfurtunatamenti, ùn hè micca supportatu da tutti i dispositi fisichi, ipervisori è sistemi operativi invitati. Attualmente, i principali dispositi chì supportanu a virtualizazione di hardware sò i prucessori.

Paravirtualizazione. L'opzione più cumuna per a virtualizazione di u dispositivu in KVM è in generale u modu di virtualizazione più cumuni per i sistemi operativi invitati. A so peculiarità hè chì u travagliu cù certi sottosistemi di ipervisori (per esempiu, cù a rete o stack di discu) o l'attribuzione di e pagine di memoria si faci cù l'API di ipervisore, senza traduzzione di cumandamenti di livellu bassu. U svantaghju di stu metudu di virtualizazione hè chì u kernel di u sistema operatore invitatu deve esse mudificatu per pudè cumunicà cù l'ipervisore cù questa API. Ma questu hè generalmente risoltu instalendu drivers speciali in u sistema operatore invitatu. In KVM questa API hè chjamata virtio API.

Cù paravirtualizazione, paragunatu à a trasmissione, u percorsu à u dispusitivu fisicu hè significativamente ridutta mandendu cumandamenti direttamente da a macchina virtuale à u prucessu di ipervisore nantu à l'ospite. Questu permette di accelerà l'esekzione di tutte l'istruzzioni in a macchina virtuale. In KVM, questu hè fattu da l'API virtio, chì travaglia solu per certi dispositi, cum'è una rete o un adattatore di discu. Hè per quessa chì i drivers virtio sò stallati in e macchine virtuali.

U svantaghju di sta accelerazione hè chì micca tutti i prucessi chì funzionanu in a macchina virtuale fermanu in questu. Questu crea alcuni effetti speciali chì ponu risultatu in spawning on steal. I ricumandemu di principià un studiu detallatu di stu prublema cù Una API per l'I/O virtuale: virtio.

2.3. Pianificazione "fiera".

Una macchina virtuale nantu à un ipervisore hè, in fattu, un prucessu ordinariu chì ubbidisce à e liggi di scheduling (distribuzione di risorse trà i prucessi) in u kernel Linux, allora fighjemu un ochju più vicinu.

Linux usa u chjamatu CFS, Completely Fair Scheduler, chì hè diventatu u pianificatore predeterminatu da u kernel 2.6.23. Per capisce stu algoritmu, pudete leghje l'Architettura di u Kernel Linux o u codice fonte. L'essenza di CFS hè di distribuisce u tempu di u processatore trà i prucessi secondu a durata di a so esecuzione. U più tempu CPU chì un prucessu richiede, menu tempu CPU riceve. Questu assicura chì tutti i prucessi sò eseguiti "fairly" - cusì chì un prucessu ùn occupa micca constantemente tutti i processori, è altri prucessi ponu ancu eseguisce.

Calchì volta stu paradigma porta à artefatti interessanti. L'utilizatori di Linux di longu tempu prubabilmente ricordanu a congelazione di un editore di testu regulare nantu à un desktop mentre eseguanu applicazioni intensive di risorse cum'è un compilatore. Questu hè accadutu perchè i travaglii chì ùn sò micca intensivi di risorse in l'applicazioni di scrittura cumpetenu cù i travaglii intensivi di risorse, cum'è u compilatore. CFS pensa chì questu hè ingiustu, cusì ferma periodicamente l'editore di testu è permette à u processatore di gestisce i compiti di u compilatore. Questu hè stata corretta cù un mecanismu sched_autogroup, ma parechje altre caratteristiche di a distribuzione di u tempu di u processatore trà e tarei sò stati. In verità, questu ùn hè micca una storia di quantu male tuttu hè in CFS, ma un tentativu di attirà l'attenzione à u fattu chì a distribuzione "giusta" di u tempu di u processatore ùn hè micca u compitu più triviale.

Un altru puntu impurtante in u scheduler hè a preemption. Questu hè necessariu per caccià u prucessu di snickering da u processatore è lasciate l'altri travaglià. U prucessu di ejection hè chjamatu cambiamentu di cuntestu. In questu casu, u cuntestu tutale di u compitu hè cunsirvatu: u statu di a pila, i registri, etc., dopu chì u prucessu hè mandatu per aspittà, è un altru piglia u so postu. Questa hè una operazione caru per u SO è hè raramente utilizatu, ma ùn ci hè nunda di sbagliatu. U cambiamentu di cuntestu frequente pò indicà un prublema in u SO, ma di solitu hè cuntinuu è ùn indica nunda in particulare.

Una storia cusì longa hè necessaria per spiegà un fattu: più risorse di processore chì un prucessu prova di cunsumà in un pianificatore Linux onestu, u più veloce serà fermatu per chì altri prucessi ponu ancu travaglià. Ch'ella sia curretta o micca, hè una quistione cumplessa chì pò esse risolta in modu diversu sottu carichi diffirenti. In Windows, finu à pocu tempu, u pianificatore era focu annantu à u trattamentu prioritariu di l'applicazioni desktop, chì puderia causà i prucessi di fondo à congelate. Sun Solaris avia cinque diverse classi di pianificatori. Quandu avemu lanciatu a virtualizazione, avemu aghjustatu un sestu, Pianificatore di sparte fiera, perchè i cinque precedenti ùn anu micca travagliatu bè cù a virtualizazione di Solaris Zones. I ricumandemu di principià un studiu detallatu di sta questione cù libri cum'è Solaris Internals: Solaris 10 è OpenSolaris Kernel Architecture o Capisce u Kernel Linux.

2.4. Cumu monitorà a robba?

U monitoraghju arrubbatu in una macchina virtuale, cum'è qualsiasi altra metrica di processore, hè simplice: pudete aduprà qualsiasi strumentu di metrica di processore. A cosa principal hè chì a macchina virtuale hè in Linux. Per una certa ragione Windows ùn furnisce micca sta infurmazione à i so utilizatori. 🙁

Output of the top command: details of the processeur load, in a colonna rightmost - steal

A difficultà nasce quandu pruvate d'ottene sta informazione da l'ipervisore. Pudete pruvà di predichendu a robba nantu à a macchina host, per esempiu, utilizendu u paràmetru Load Average (LA) - u valore mediu di u nùmeru di prucessi chì aspetta in a fila d'esekzione. U metudu per u calculu di stu paràmetru ùn hè micca simplice, ma in generale, se LA normalizata da u numeru di filamenti di u processatore hè più di 1, questu indica chì u servitore Linux hè sopracarcatu cù qualcosa.

Chì sò tutti questi prucessi chì aspettanu? A risposta ovvia hè u processatore. Ma a risposta ùn hè micca sanu sanu currettu, perchè qualchì volta u prucissuri hè liberu, ma LA va fora di scala. Ricurdativi cumu si cascanu NFS è cumu LA cresce. U listessu pò accade cù un discu è altri dispositi input / output. Ma in fattu, i prucessi ponu aspittà à a fine di ogni serratura, sia fisica, assuciata à un dispositivu I / O, o logica, cum'è un mutex. Questu include ancu chjusi à u livellu di hardware (a stessa risposta da u discu), o logica (i primitivi di chjusi chjamati, chì includenu una mansa di entità, mutex adaptive è spin, semafori, variabili di cundizione, rw locks, ipc locks). ...).

Una altra caratteristica di LA hè chì hè cunsideratu cum'è un sistema upirativu mediu. Per esempiu, 100 prucessi sò in competizione per un schedariu, è dopu LA = 50. Un valore cusì grande pare chì indicà chì u sistema operatore hè male. Ma per un altru codice scritta in crookedly, questu pò esse un statu normale, malgradu u fattu chì solu hè male, è altri prucessi in u sistema upirativu ùn soffrenu micca.

A causa di questa media (è in micca menu di un minutu), determinà qualcosa da l'indicatore LA ùn hè micca u compitu più gratificante, cù risultati assai incerti in casi specifichi. Sè vo pruvate à capisce, truverete chì l'articuli in Wikipedia è altre risorse dispunibuli descrizanu solu i casi più simplici, senza una spiegazione prufonda di u prucessu. Mando à tutti quelli chì sò interessati, di novu, quì à Brendan Gregg  - seguitate i ligami sottu. Quale hè troppu pigro per parlà inglese - traduzzione di u so articulu populari nantu à LA.

3. Effetti spiciali

Avà guardemu i casi principali di arrubà chì avemu scontru. Vi dicu cumu seguitanu da tutte e cose sopra è cumu si sò in relazione cù l'indicatori nantu à l'ipervisore.

Riciclà. U più simplice è cumuni: l'ipervisore hè stata riutilizata. Infatti, ci sò assai macchine virtuali in esecuzione, altu cunsumu di processore in elli, assai cuncurrenza, l'utilizazione LA hè più di 1 (normalizata da i filamenti di processore). Tuttu l'internu di tutte e macchine virtuali rallenta. Steal trasmessi da l'hypervisor hè ancu crescente, hè necessariu di redistribuisce a carica o disattivà qualcunu. In generale, tuttu hè logicu è capiscenu.

Paravirtualization vs Single Instances. Ci hè una sola macchina virtuale nantu à l'ipervisore; cunsuma una piccula parte di questu, ma pruduce una grande carica I / O, per esempiu nantu à u discu. È da un locu un picculu robba apparisce in questu, finu à u 10% (cum'è mostratu da parechji esperimenti).

U casu hè interessante. Steal appare quì precisamente per via di u bluccatu à u livellu di i cunduttori paravirtualizzati. Una interruzzione hè creata in a macchina virtuale, trattata da u cunduttore è mandata à l'ipervisore. A causa di a manipulazione di l'interruzzione nantu à l'ipervisore, per a macchina virtuale s'assumiglia una dumanda mandata, hè pronta per l'esekzione è aspetta per u processatore, ma ùn hè micca datu u tempu di processatore. A zitella virtuale pensa chì sta volta hè stata arrubbata.

Questu succede à u mumentu chì u buffer hè mandatu, entra in u spaziu kernel di l'hypervisor, è cuminciamu à aspittà. Ancu s'ellu, da u puntu di vista di a macchina virtuale, deve vultà immediatamente. Per quessa, sicondu l'algoritmu di calculu steal, sta volta hè cunsideratu arrubatu. Hè assai prubabile, in questa situazione, ci ponu esse altri miccanismi (per esempiu, trasfurmà qualchì altra chjama di sistema), ma ùn deve esse assai diffirenti.

Scheduler versus macchine virtuali altamente caricate. Quandu una macchina virtuale soffre di robba più di l'altri, questu hè dovutu à u pianificatore. Quantu più un prucessu carica u processatore, u più prestu u pianificatore l'abbandunarà per chì l'altri ponu ancu travaglià. Sè a macchina virtuale cunsuma pocu, ùn vi guasi vede arrubbari: u so prucessu onestamente pusatu è aspittatu, avemu bisognu di dà più tempu. Se una macchina virtuale pruduce a carica massima nantu à tutti i so core, hè spessu cacciatu da u processatore è pruvate micca di dà assai tempu.

Hè ancu peggiu quandu i prucessi in a macchina virtuale pruvate d'avè più processatore perchè ùn ponu micca affruntà u trattamentu di dati. Allora u sistema operatore nantu à l'ipervisore, per via di l'ottimisazione onesta, furnisce menu è menu tempu di processore. Stu prucessu si faci cum'è una valanga, è arrubbanu salti à u celu, ancu s'è altre machini virtuale ùn ponu micca avvistu. E più core, u peghju hè a macchina affettata. In breve, e macchine virtuali altamente caricate cù assai core soffrenu più.

Low LA, ma ci hè un furtu. Se LA hè apprussimatamente 0,7 (vale à dì, l'ipervisore pare esse sottucarcatu), ma u furtu hè osservatu ind'è e macchine virtuali individuali:

• L'opzione cù paravirtualizazione digià descritta sopra. A macchina virtuale pò riceve metriche chì indicanu steal, anche se l'ipervisore hè bè. Sicondu i risultati di i nostri esperimenti, sta opzione di robba ùn supera u 10% è ùn deve micca avè un impattu significativu in u rendiment di l'applicazioni in a macchina virtuale.
• U paràmetru LA hè calculatu incorrectly. Più precisamente, in ogni mumentu specificu hè calculatu currettamente, ma quandu u mediu di più di un minutu risulta esse sottovalutatu. Per esempiu, se una macchina virtuale per terzu di l'ipervisore cunsuma tutti i so prucessori per esattamente a mità di minutu, allora LA per minutu nantu à l'ipervisore serà 0,15; quattru tali macchine virtuali chì travaglianu simultaneamente daranu 0,6. È u fattu chì per una mità di minutu nantu à ognunu di elli ci era un furtu salvaticu à 25% secondu l'indicatore LA ùn pò più esse tiratu fora.
• Di novu, per via di u pianificatore chì hà decisu chì qualchissia manghjava troppu è lasciò chì qualchissia aspetta. Intantu, cambiaraghju u cuntestu, trattà l'interruzioni è piglià cura di altre cose impurtanti di u sistema. In u risultatu, alcune macchine virtuali ùn vedenu micca prublemi, mentre chì altri sperimentanu una seria degradazione di u rendiment.

4. Altre distorsioni

Ci hè un milione di motivi più per distorte u ritornu ghjustu di u tempu di u processatore in una macchina virtuale. Per esempiu, l'hyperthreading è NUMA introducenu difficultà in i calculi. Confundenu cumplettamente l'scelta di u kernel per eseguisce u prucessu, perchè u pianificatore usa coefficienti - pesi, chì facenu u calculu ancu più difficiule quandu cambia u cuntestu.

Ci sò distorsioni per tecnulugii cum'è turbo boost o, à u cuntrariu, u modu di risparmiu d'energia, chì, quandu calcula l'utilizazione, ponu aumentà artificialmente o diminuite a freccia o ancu a slice di tempu nantu à u servitore. L'attivazione di turbo boost riduce u rendiment di un filu di processore per via di un aumentu di u rendiment di un altru. À questu mumentu, l'infurmazioni nantu à a freccia di u processatore attuale ùn hè micca trasmessa à a macchina virtuale, è crede chì qualchissia hè arrubbatu u so tempu (per esempiu, hà dumandatu 2 GHz, ma hà ricevutu a mità di questu).

In generale, ci ponu esse parechje motivi di distorsioni. Pudete truvà qualcosa altru nantu à un sistema particulari. Hè megliu principià cù i libri à quale aghju datu ligami sopra, è ricuperà statistiche da l'ipervisore utilizendu utilità cum'è perf, sysdig, systemtap, di quale decine.

5. Cunclusioni

1. Una certa quantità di arrubbata pò accade per via di a paravirtualizazione, è pò esse cunsiderata normale. Scrivenu in Internet chì stu valore pò esse 5-10%. Dipende da l'applicazioni in a macchina virtuale è da a carica chì mette nantu à i so dispositi fisici. Quì hè impurtante prestu attenzione à cumu si sentenu l'applicazioni in e macchine virtuali.
2. U rapportu di a carica nantu à l'ipervisore è a robba in a macchina virtuale ùn sò micca sempre chjaramente interrelati; e duie stime di arrubà ponu esse sbagliate in situazioni specifiche sottu carichi differenti.
3. U pianificatore hà una mala attitudine versu i prucessi chì dumandanu assai. Pruva di dà menu à quelli chì dumandanu di più. I grandi macchine virtuali sò male.
4. Un pocu steal pò esse a norma ancu senza paravirtualizazione (pigliandu in contu a carica in a macchina virtuale, e caratteristiche di a carica di i vicini, a distribuzione di carica in i fili è altri fattori).
5. Se vulete scopre a robba in un sistema specificu, duvete scopre diverse opzioni, cullà metriche, analizà cun cura è pensate à cumu distribuisce uniformemente a carica. E deviazioni da ogni casu sò pussibuli, chì deve esse cunfirmata sperimentalmente o guardate in u debugger di u kernel.

Source: www.habr.com