Hola! Vull parlar-vos en termes senzills sobre la mecànica del robatori dins de les màquines virtuals i sobre alguns artefactes no evidents que vam aconseguir esbrinar durant la seva investigació, en els quals vaig haver de submergir-me com a director tècnic d'una plataforma al núvol. . La plataforma funciona amb KVM.
El temps de robatori de la CPU és el temps durant el qual la màquina virtual no rep recursos del processador per a la seva execució. Aquest temps només es compta en sistemes operatius convidats en entorns de virtualització. Les raons per on van aquests recursos més assignats, com a la vida, són molt vagues. Però vam decidir esbrinar-ho i fins i tot vam dur a terme diversos experiments. No és que ara ho sabem tot sobre robatori, però ara us explicarem alguna cosa interessant.
1. Què és robar
Per tant, robar és una mètrica que indica la manca de temps del processador per als processos dins d'una màquina virtual. Com està descrit El sigil és el temps durant el qual l'hipervisor executa altres processos al sistema operatiu amfitrió tot i que ha posat a la cua el procés de la màquina virtual per a l'execució. És a dir, robar es calcula com la diferència entre el temps en què el procés està a punt per executar-se i el temps en què el procés té assignat temps de processador.
El nucli de la màquina virtual rep la mètrica de robatori de l'hipervisor. Al mateix temps, l'hipervisor no especifica exactament quins altres processos està executant, simplement diu "mentre estic ocupat, no et puc donar temps". A KVM, s'ha afegit suport per al càlcul de robatoris . Aquí hi ha dos punts clau:
- La màquina virtual aprèn sobre robar des de l'hipervisor. És a dir, des del punt de vista de les pèrdues, per als processos de la pròpia màquina virtual es tracta d'una mesura indirecta que pot estar subjecta a diverses distorsions.
- L'hipervisor no comparteix informació amb la màquina virtual sobre què més està fent; el més important és que no hi dedica temps. Per això, la pròpia màquina virtual no pot detectar distorsions en l'indicador de robatori, que es podria avaluar per la naturalesa dels processos competidors.
2. Què afecta el robatori
2.1. Roba càlcul
Essencialment, el robatori es calcula aproximadament igual que el temps d'utilització normal de la CPU. No hi ha molta informació sobre com es considera el reciclatge. Probablement perquè la majoria de la gent considera aquesta pregunta òbvia. Però aquí també hi ha trampes. Per familiaritzar-vos amb aquest procés, podeu llegir : aprendràs molts matisos a l'hora de calcular la utilització i sobre situacions en què aquest càlcul serà erroni per les raons següents:
- El processador es sobreescalfa, fent que els cicles es saltin.
- Activa/desactiva l'impuls turbo, que canvia la freqüència de rellotge del processador.
- Un canvi en la durada del període de temps que es produeix quan s'utilitzen tecnologies d'estalvi d'energia del processador, com ara SpeedStep.
- El problema amb el càlcul de la mitjana: estimar la utilització d'un minut al 80% pot amagar una explosió a curt termini del 100%.
- Un bloqueig de rotació fa que es recuperi el processador, però el procés de l'usuari no veu cap progrés en la seva execució. Com a resultat, la utilització calculada del processador pel procés serà del cent per cent, tot i que el procés no consumirà físicament temps del processador.
No he trobat cap article que descrigui un càlcul similar per robar (si ho sabeu, compartiu-lo als comentaris). Però, a jutjar pel codi font, el mecanisme de càlcul és el mateix que per al reciclatge. Simplement, s'afegeix un altre comptador al nucli, directament per al procés KVM (procés de màquina virtual), que compta la durada del procés KVM esperant el temps de la CPU. El comptador pren informació sobre el processador de la seva especificació i comprova si totes les seves marques són utilitzades pel procés de la màquina virtual. Si això és tot, suposem que el processador només estava ocupat amb el procés de la màquina virtual. En cas contrari, informem que el processador estava fent una altra cosa, va aparèixer robatori.
El procés de recompte de robatoris està subjecte als mateixos problemes que el recompte habitual del reciclatge. No vol dir que aquests problemes apareguin sovint, però semblen desanimadors.
2.2. Tipus de virtualització en KVM
A grans trets, hi ha tres tipus de virtualització, tots compatibles amb KVM. El mecanisme d'ocurrència del robatori pot dependre del tipus de virtualització.
Emissió. En aquest cas, el funcionament del sistema operatiu de la màquina virtual amb dispositius d'hipervisor físic es produeix com això:
- El sistema operatiu convidat envia una ordre al seu dispositiu convidat.
- El controlador del dispositiu convidat rep l'ordre, genera una sol·licitud per a la BIOS del dispositiu i l'envia a l'hipervisor.
- El procés d'hipervisor tradueix l'ordre a l'ordre per al dispositiu físic, fent-lo, entre altres coses, més segur.
- El controlador del dispositiu físic accepta l'ordre modificada i l'envia al propi dispositiu físic.
- Els resultats de l'execució d'ordres tornen pel mateix camí.
L'avantatge de la traducció és que permet emular qualsevol dispositiu i no requereix una preparació especial del nucli del sistema operatiu. Però això s'ha de pagar, primer de tot, en velocitat.
Virtualització de maquinari. En aquest cas, el dispositiu a nivell de maquinari entén les ordres del sistema operatiu. Aquesta és la manera més ràpida i millor. Però, malauradament, no és compatible amb tots els dispositius físics, hipervisors i sistemes operatius convidats. Actualment, els principals dispositius que admeten la virtualització de maquinari són els processadors.
Paravirtualització. L'opció més habitual per a la virtualització de dispositius en KVM i, en general, el mode de virtualització més comú per als sistemes operatius convidats. La seva particularitat és que el treball amb alguns subsistemes d'hipervisor (per exemple, amb la xarxa o la pila de disc) o l'assignació de pàgines de memòria es produeix mitjançant l'API de l'hipervisor, sense traduir ordres de baix nivell. El desavantatge d'aquest mètode de virtualització és que s'ha de modificar el nucli del sistema operatiu convidat perquè es pugui comunicar amb l'hipervisor mitjançant aquesta API. Però això normalment es soluciona instal·lant controladors especials al sistema operatiu convidat. A KVM aquesta API s'anomena .
Amb la paravirtualització, en comparació amb la difusió, el camí cap al dispositiu físic es redueix significativament enviant ordres directament des de la màquina virtual al procés d'hipervisor de l'amfitrió. Això us permet accelerar l'execució de totes les instruccions dins de la màquina virtual. A KVM, això ho fa l'API virtio, que només funciona per a determinats dispositius, com ara un adaptador de xarxa o de disc. És per això que els controladors virtio s'instal·len dins de les màquines virtuals.
L'inconvenient d'aquesta acceleració és que no tots els processos que s'executen dins de la màquina virtual romanen dins d'ella. Això crea alguns efectes especials que poden provocar la generació en robatori. Recomano començar un estudi detallat d'aquest problema amb .
2.3. Programació "justa".
Una màquina virtual en un hipervisor és, de fet, un procés ordinari que obeeix a les lleis de la programació (distribució de recursos entre processos) al nucli de Linux, així que mirem-ho més de prop.
Linux utilitza l'anomenat CFS, Completely Fair Scheduler, que s'ha convertit en el programador predeterminat des del nucli 2.6.23. Per entendre aquest algorisme, podeu llegir l'arquitectura del nucli de Linux o el codi font. L'essència de CFS és distribuir el temps del processador entre processos en funció de la durada de la seva execució. Com més temps de CPU requereix un procés, menys temps de CPU rebrà. Això garanteix que tots els processos s'executen "de manera justa", de manera que un procés no ocupi constantment tots els processadors i altres processos també es poden executar.
De vegades, aquest paradigma porta a artefactes interessants. Els usuaris de Linux de molt de temps probablement recorden la congelació d'un editor de text normal a un escriptori mentre executen aplicacions que consumeixen molts recursos, com ara un compilador. Això va passar perquè les tasques no intensives en recursos a les aplicacions d'escriptori competien amb tasques intensives en recursos, com ara el compilador. CFS creu que això és injust, de manera que atura periòdicament l'editor de text i deixa que el processador s'ocupi de les tasques del compilador. Això es va corregir mitjançant un mecanisme , però es van mantenir moltes altres característiques de la distribució del temps del processador entre tasques. De fet, no es tracta d'una història sobre com de dolent està tot a CFS, sinó d'un intent de cridar l'atenció sobre el fet que la distribució "justa" del temps del processador no és la tasca més trivial.
Un altre punt important del planificador és la preempció. Això és necessari per expulsar el procés de riure del processador i deixar que altres funcionin. El procés d'expulsió s'anomena canvi de context. En aquest cas, es conserva tot el context de la tasca: l'estat de la pila, registres, etc., després del qual s'envia el procés a esperar i un altre ocupa el seu lloc. Aquesta és una operació cara per al sistema operatiu i s'utilitza poques vegades, però no hi ha res inherentment dolent. El canvi de context freqüent pot indicar un problema al sistema operatiu, però normalment és continu i no indica res en particular.
Es necessita una història tan llarga per explicar un fet: com més recursos de processador intenti consumir un procés en un planificador Linux honest, més ràpid s'aturarà perquè altres processos també puguin funcionar. Si això és correcte o no és una qüestió complexa que es pot resoldre de manera diferent sota diferents càrregues. A Windows, fins fa poc, el planificador es va centrar en el processament prioritari d'aplicacions d'escriptori, que podria provocar que els processos en segon pla es congelessin. Sun Solaris tenia cinc classes diferents de planificadors. Quan vam llançar la virtualització, vam afegir un sisè, , perquè els cinc anteriors no funcionaven adequadament amb la virtualització de Solaris Zones. Recomano començar un estudi detallat d'aquest tema amb llibres com o .
2.4. Com controlar el robatori?
Supervisar el robatori dins d'una màquina virtual, com qualsevol altra mètrica del processador, és senzill: podeu utilitzar qualsevol eina de mètriques del processador. El més important és que la màquina virtual està a Linux. Per alguna raó Windows no proporciona aquesta informació als seus usuaris. 🙁
Sortida de l'ordre superior: detalls de la càrrega del processador, a la columna més dreta - robar
La dificultat sorgeix quan s'intenta obtenir aquesta informació de l'hipervisor. Podeu provar de predir el robatori a la màquina amfitriona, per exemple, utilitzant el paràmetre Load Average (LA), el valor mitjà del nombre de processos esperant a la cua d'execució. El mètode per calcular aquest paràmetre no és senzill, però en general, si LA normalitzada pel nombre de fils del processador és superior a 1, això indica que el servidor Linux està sobrecarregat amb alguna cosa.
A què esperen tots aquests processos? La resposta òbvia és el processador. Però la resposta no és del tot correcta, perquè de vegades el processador és gratuït, però LA surt d'escala. Recordeu . El mateix pot passar amb un disc i altres dispositius d'entrada/sortida. Però, de fet, els processos poden esperar al final de qualsevol bloqueig, ja sigui físic, associat a un dispositiu d'E/S, o lògic, com ara un mutex. Això també inclou el bloqueig a nivell de maquinari (la mateixa resposta del disc) o la lògica (les anomenades primitives de bloqueig, que inclouen un munt d'entitats, mutex adaptatiu i spin, semàfors, variables de condició, bloquejos rw, bloquejos ipc). ...).
Una altra característica de LA és que es considera un sistema operatiu mitjà. Per exemple, 100 processos competeixen per un fitxer i després LA=50. Un valor tan gran semblaria indicar que el sistema operatiu és dolent. Però per a altres codis escrits malament, aquest pot ser un estat normal, malgrat que només és dolent i altres processos del sistema operatiu no pateixen.
A causa d'aquesta mitjana (i en no menys d'un minut), determinar qualsevol cosa per l'indicador LA no és la tasca més gratificant, amb resultats molt incerts en casos concrets. Si intenteu esbrinar-ho, trobareu que els articles de la Viquipèdia i altres recursos disponibles descriuen només els casos més senzills, sense una explicació profunda del procés. Envio de nou a tothom que estigui interessat, - seguiu els enllaços següents. Qui és massa mandrós per parlar anglès? .
3. Efectes especials
Vegem ara els principals casos de robatori que hem trobat. Us explicaré com segueixen tot l'anterior i com es relacionen amb els indicadors de l'hipervisor.
Reciclatge. El més senzill i habitual: s'ha reutilitzat l'hipervisor. De fet, hi ha moltes màquines virtuals en execució, un alt consum de processador al seu interior, molta competència, la utilització de LA és superior a 1 (normalitzada per fils del processador). Tot dins de totes les màquines virtuals s'alenteix. El robatori transmès des de l'hipervisor també està creixent, cal redistribuir la càrrega o apagar algú. En general, tot és lògic i comprensible.
Paravirtualització vs. instàncies individuals. Només hi ha una màquina virtual a l'hipervisor; en consumeix una petita part, però produeix una gran càrrega d'E/S, per exemple al disc. I des d'algun lloc hi apareix un petit robatori, fins a un 10% (com ho demostren diversos experiments).
El cas és interessant. Steal apareix aquí precisament pel bloqueig a nivell de controladors paravirtualitzats. Es crea una interrupció dins de la màquina virtual, processada pel controlador i enviada a l'hipervisor. A causa del maneig d'interrupcions a l'hipervisor, per a la màquina virtual sembla una sol·licitud enviada, està llesta per a l'execució i està esperant el processador, però no se li dóna temps de processador. La noia virtual creu que aquesta vegada l'han robat.
Això passa en el moment en què s'envia el buffer, entra a l'espai del nucli de l'hipervisor i el comencem a esperar. Encara que, des del punt de vista de la màquina virtual, hauria de tornar immediatament. Per tant, segons l'algoritme de càlcul de robatori, aquesta vegada es considera robada. El més probable és que en aquesta situació hi hagi altres mecanismes (per exemple, processar altres trucades del sistema), però no haurien de ser gaire diferents.
Programador versus màquines virtuals molt carregades. Quan una màquina virtual pateix robatori més que altres, això es deu al planificador. Com més carregui un procés el processador, més aviat el planificador el desactivarà perquè els altres també puguin funcionar. Si la màquina virtual consumeix poc, difícilment veurà robar: el seu procés honestament s'ha assegut i esperat, hem de donar-li més temps. Si una màquina virtual produeix la màxima càrrega en tots els seus nuclis, sovint és expulsada del processador i intenten no donar-li molt de temps.
És encara pitjor quan els processos dins de la màquina virtual intenten obtenir més processador perquè no poden fer front al processament de dades. Aleshores, el sistema operatiu de l'hipervisor, a causa d'una optimització honesta, proporcionarà cada cop menys temps de processador. Aquest procés es produeix com una allau, i el robatori salta al cel, encara que altres màquines virtuals gairebé no ho notin. I com més nuclis, pitjor serà la màquina afectada. En resum, les màquines virtuals molt carregades amb molts nuclis pateixen més.
Baixa LA, però hi ha robatori. Si LA és d'aproximadament 0,7 (és a dir, l'hipervisor sembla estar poc carregat), però s'observa robatori dins de màquines virtuals individuals:
- L'opció amb paravirtualització ja descrita anteriorment. La màquina virtual pot rebre mètriques que indiquen robatori, tot i que l'hipervisor està bé. Segons els resultats dels nostres experiments, aquesta opció de robatori no supera el 10% i no hauria de tenir un impacte significatiu en el rendiment de les aplicacions dins de la màquina virtual.
- El paràmetre LA es calcula incorrectament. Més precisament, en cada moment concret es calcula correctament, però quan es fa una mitjana d'un minut resulta que està infravalorat. Per exemple, si una màquina virtual per terç de l'hipervisor consumeix tots els seus processadors durant exactament mig minut, llavors LA per minut a l'hipervisor serà de 0,15; quatre d'aquestes màquines virtuals treballant simultàniament donaran 0,6. I el fet que durant mig minut en cadascun d'ells hi hagi hagut un robatori salvatge al 25% segons l'indicador LA ja no es pot treure.
- De nou, a causa del planificador que va decidir que algú menjava massa i va deixar que algú esperés. Mentrestant, canviaré el context, gestionaré les interrupcions i m'encarregaré d'altres coses importants del sistema. Com a resultat, algunes màquines virtuals no veuen cap problema, mentre que altres experimenten una greu degradació del rendiment.
4. Altres distorsions
Hi ha un milió de raons més per distorsionar el retorn just del temps del processador en una màquina virtual. Per exemple, hyperthreading i NUMA introdueixen dificultats en els càlculs. Confonen completament l'elecció del nucli per executar el procés, perquè el planificador utilitza coeficients - pesos, que dificulten encara més el càlcul quan es canvia de context.
Hi ha distorsions a causa de tecnologies com el turbo boost o, per contra, el mode d'estalvi d'energia, que, a l'hora de calcular la utilització, poden augmentar o disminuir artificialment la freqüència o fins i tot el tram de temps al servidor. L'habilitació del turbo boost redueix el rendiment d'un fil del processador a causa d'un augment del rendiment d'un altre. En aquest moment, la informació sobre la freqüència actual del processador no es transmet a la màquina virtual, i creu que algú li està robant el temps (per exemple, va demanar 2 GHz, però en va rebre la meitat).
En general, hi pot haver moltes raons per a la distorsió. És possible que trobeu alguna cosa més en un sistema determinat. És millor començar amb els llibres als quals vaig donar enllaços més amunt i recuperar estadístiques de l'hipervisor mitjançant utilitats com perf, sysdig, systemtap, de les quals .
5. Conclusions
- Es pot produir una certa quantitat de robatori a causa de la paravirtualització, i es pot considerar normal. Escriuen a Internet que aquest valor pot ser del 5-10%. Depèn de les aplicacions dins de la màquina virtual i de la càrrega que posi als seus dispositius físics. Aquí és important parar atenció a com se senten les aplicacions dins de les màquines virtuals.
- La relació de càrrega a l'hipervisor i robatori dins de la màquina virtual no sempre estan clarament interrelacionades; ambdues estimacions de robatori poden ser errònies en situacions específiques amb diferents càrregues.
- El planificador té una mala actitud davant els processos que demanen molt. Intenta donar menys als qui demanen més. Les grans màquines virtuals són males.
- Una mica de robatori pot ser la norma fins i tot sense paravirtualització (tenint en compte la càrrega dins de la màquina virtual, les característiques de la càrrega dels veïns, la distribució de la càrrega entre fils i altres factors).
- Si voleu esbrinar el robatori en un sistema específic, heu d'explorar diverses opcions, recopilar mètriques, analitzar-les acuradament i pensar com distribuir la càrrega de manera uniforme. Són possibles desviacions de qualsevol cas, que s'han de confirmar experimentalment o mirar al depurador del nucli.
Font: www.habr.com