Hej! Jag vill förklara pÄ ett enkelt sÀtt mekaniken bakom hur steal uppstÄr inom virtuella maskiner och nÄgra mindre uppenbara artefakter som vi har lyckats utredda under vÄr forskning, vilket jag har dykt ner i som teknisk chef för den molnbaserade plattformen. . Plattformen körs pÄ KVM.
CPU steal time Àr den tid dÄ den virtuella maskinen inte fÄr resurser frÄn processorn för sin bearbetning. Denna tid rÀknas endast i gÀstoperativsystem inom virtualiseringsmiljöer. Orsakerna till vart de tilldelade resurserna tar vÀgen, Àr liksom i livet, ganska oklara. Men vi beslutade att göra en utredning och satte igÄng en rad experiment. Inte sÄ att vi nu vet allt om steal, men vi kan berÀtta en del intressanta saker.
1. Vad Àr steal
SÄ, steal Àr en metrik som indikerar brist pÄ processtid för processerna inuti den virtuella maskinen. Som beskrivs , Àr steal den tid dÄ hypervisorn utför andra processer pÄ vÀrdoperativsystemet, Àven om den har stÀllt den virtuella maskinens process i kö för utförande. Det vill sÀga, steal rÀknas som skillnaden mellan tiden dÄ processen Àr redo att utföras och tiden dÄ processorn tilldelas tid.
Steal-metriken fÄr den virtuella maskinens kÀrna frÄn hypervisorn. Hypervisorn klargör inte heller vilka andra processer den utför, den sÀger bara "jag Àr upptagen, jag kan inte ge dig tid just nu". PÄ KVM har stödet för att rÀkna steal lagts till i Det finns tvÄ nyckelpunkter hÀr:
- Den virtuella maskinen fÄr veta om steal frÄn hypervisorn. Det vill sÀga, vad gÀller förluster, Àr detta en indirekt mÀtning för processerna pÄ sjÀlva virtuella maskinen, som kan vara utsatt för olika förvrÀngningar.
- Hypervisorn delar inte med sig till den virtuella maskinen om vad den Ă€r upptagen med â det viktiga Ă€r att den inte ger tid till den. PĂ„ grund av detta kan den virtuella maskinen inte identifiera förvrĂ€ngningar i steal-mĂ„ttet, som skulle kunna bedömas utifrĂ„n karaktĂ€ren av konkurrerande processer.
2. Vad pÄverkar steal
2.1. BerÀkning av steal
I grunden berÀknas steal pÄ ungefÀr samma sÀtt som den vanliga CPU-anvÀndningstiden. Det finns inte mycket information om hur anvÀndning berÀknas. Kanske för att de flesta anser att det Àr en uppenbar frÄga. Men hÀr finns det ocksÄ fallgropar. För att bekanta sig med denna process kan man lÀsa : du kommer att lÀra dig om en mÀngd olika nyanser vid berÀkning av utnyttjande och om situationer dÄ denna berÀkning kan vara felaktig av följande skÀl:
- Ăverhettning av processorn dĂ€r takter gĂ„r förlorade.
- Aktivering / deaktivering av turboboost, vilket resulterar i att processorhastigheten förÀndras.
- Ăndring av tidskvantens lĂ€ngd, som sker vid anvĂ€ndning av strömsparande teknologier för processorn, som till exempel SpeedStep.
- Problemet med att berÀkna genomsnittet: en utnyttjandeprocent pÄ 80 % under en minut kan dölja en kortvarig spik pÄ 100 %.
- Cykelblockering (spin lock) resulterar i att processorn utnyttjas, men anvÀndarprocessen ser ingen framsteg i sin körning. DÀrmed kommer den berÀknade utnyttjandegraden för processorn av processen att vara 100 %, Àven om den fysiska processortiden inte kommer att anvÀndas.
I artiklar som beskriver en sĂ„dan berĂ€kning för steal, har jag inte hittat nĂ„got (om du vet â dela gĂ€rna med dig i kommentarerna). Men, enligt kĂ€llkoden, Ă€r berĂ€kningsmekanismen densamma som för utnyttjande. Det lĂ€ggs helt enkelt till en annan rĂ€knare i kĂ€rnan, direkt för KVM-processen (virtuell maskinprocess), som rĂ€knar hur lĂ€nge KVM-processen har varit i vĂ€ntelĂ€ge för processor-tid. RĂ€knaren fĂ„r information om processorn frĂ„n dess specifikation och kontrollerar om alla dess takter har utnyttjats av virtuella maskinen. Om allt Ă€r utnyttjat, betraktar vi det som att processorn bara har jobbat med den virtuella maskinen. Annars informerar vi om att processorn varit upptagen med nĂ„got annat, att steal har uppstĂ„tt.
Processen för att berÀkna steal Àr utsatt för samma problem som den vanliga utnyttjandeberÀkningen. Man kan inte sÀga att sÄdana problem ofta uppstÄr, men de ser nedslÄende ut.
2.2. Typer av virtualisering pÄ KVM
Generellt finns det tre typer av virtualisering, och alla stöds av KVM. Typen av virtualisering kan pÄverka mekanismen för hur steal uppstÄr.
ĂversĂ€ttning. I det hĂ€r fallet fungerar operativsystemet pĂ„ den virtuella maskinen med hypervisorns fysiska enheter pĂ„ följande sĂ€tt:
- Det gÀstoperativsystemet skickar ett kommando till sin gÀst-enhet.
- Drivrutinen för gÀst-enheten tar emot kommandot, formar en begÀran till enhetens BIOS och skickar den till hypervisorn.
- Hypervisorprocessen översÀtter kommando till kommando för den fysiska enheten, vilket gör det, bland annat, sÀkrare.
- Drivern för den fysiska enheten tar emot det modifierade kommandot och skickar det redan till den fysiska enheten.
- Resultaten av utförda kommandon gÄr tillbaka lÀngs samma vÀg.
Fördelen med översÀttning Àr att den möjliggör emulering av vilken enhet som helst och inte krÀver speciell förberedelse av operativsystemets kÀrna. Men detta fÄr man betala för, frÀmst i form av prestanda.
HÄrdvaruvirtualisering. I det hÀr fallet förstÄr enheten pÄ hÄrdvarunivÄ kommandon frÄn operativsystemet. Det Àr det snabbaste och bÀsta sÀttet. Men tyvÀrr stöds det inte av alla fysiska enheter, hypervisorer och gÀstoperativsystem. För nÀrvarande Àr de huvudsakliga enheterna som stöder hÄrdvaruvirtualisering processorer.
Paravirtualisering (paravirtualization). Den mest utbredda varianten av enhetsvirtualisering pÄ KVM och generellt den mest anvÀnda virtualiseringslÀget för gÀstoperativsystem. Dess kÀnnetecken Àr att arbete med vissa delsystem av hypervisorn (till exempel nÀtverks- eller diskstack) eller allokering av minnessidor sker med anvÀndning av hypervisorens API, utan översÀttning av lÄgnivÄkommandon. Nackdelen med denna virtualiseringsmetod Àr behovet av att modifiera kÀrnan i det gÀstoperativsystemet för att kunna interagera med hypervisorn via detta API. Men detta löses vanligtvis genom att installera speciella drivrutiner pÄ gÀstoperativsystemet. I KVM kallas detta API .
Vid paravirtualisering, jÀmfört med översÀttning, förkortas vÀgen till den fysiska enheten avsevÀrt genom att skicka kommandon direkt frÄn den virtuella maskinen till hypervisorprocessen pÄ vÀrden. Detta gör att alla instruktioner inom den virtuella maskinen kan utföras snabbare. I KVM ansvarar virtio API för detta, som endast fungerar för vissa enheter, som nÀtverks- eller diskadapter. Just dÀrför installeras virtio-drivrutiner inuti virtuella maskiner.
Baksidan av en sÄdan accelerering Àr att inte alla processer som körs inuti virtuella maskiner stannar dÀr. Detta skapar vissa specialeffekter, som kan leda till att de dyker upp pÄ steal. Jag rekommenderar att noggrant studera denna frÄga som en början. .
2.3. "RÀttvis" schemalÀggning
En virtuell maskin pÄ hypervisor Àr i praktiken en vanlig process som följer reglerna för schemalÀggning (resursfördelning mellan processer) i Linux-kÀrnan, sÄ vi ska titta nÀrmare pÄ den.
I Linux anvÀnds det sÄ kallade CFS, Completely Fair Scheduler, som frÄn kÀrna 2.6.23 blev standard schemalÀggare. För att förstÄ denna algoritm kan man lÀsa Linux Kernel Architecture eller kÀllkoden. CFS:s syfte Àr att fördela processor tid mellan processer beroende pÄ hur lÀnge de körs. Ju mer processor tid en process krÀver, desto mindre tid fÄr den. Detta garanterar "rÀttvis" behandling av alla processer - sÄ att en process inte stÀndigt tar upp alla processorer, och de andra processerna ocksÄ kan köras.
Ibland leder en sÄdan paradigm till intressanta artefakter. LÄngvariga anvÀndare av Linux minns sÀkert att vanliga textredigerare pÄ skrivbordet hÀngde sig nÀr resurskrÀvande program som kompilatorer kördes. Detta hÀnde eftersom icke-resurskrÀvande uppgifter i skrivbordsapplikationer konkurrerade med uppgifter som aktivt krÀvde resurser, som kompilatorn. CFS anser att detta Àr ojuste, sÄ den stoppar periodiskt textredigeraren för att ge processorn möjlighet att hantera kompilatorns uppgifter. Detta ÄtgÀrdades med hjÀlp av mekanismen , men mÄnga andra sÀrskildheter i fördelningen av processor tid mellan uppgifter kvarstÄr. Egentligen handlar detta inte om att allt Àr dÄligt i CFS, utan om att uppmÀrksamma att "rÀttvis" fördelning av processor tid inte Àr en trivial uppgift.
En annan viktig punkt i schemalÀggaren Àr preemption. Detta Àr nödvÀndigt för att kunna avbryta en process som tar för mycket resurser och ge andra processer en chans att köra. Processen att avbryta kallas context switching, dÀr processorns kontext vÀxlas. Under denna process sparas hela kontexten för uppgiften: stakens tillstÄnd, register och sÄ vidare, varefter processen placeras i vÀntande lÀge och en annan tar dess plats. Detta Àr en kostsam operation för operativsystemet, och den anvÀnds sÀllan, men i grund och botten Àr det inget dÄligt med det. Frekvent kontextbyten kan indikera ett problem i operativsystemet, men vanligtvis sker det kontinuerligt och pekar inte pÄ nÄgot sÀrskilt.
Denna lÄnga berÀttelse behövs för att förklara en sak: ju fler resurser processorn försöker konsumera i en rÀttvis schemalÀggare i Linux, desto snabbare kommer den att stoppas sÄ att andra processer ocksÄ kan köra. Om detta Àr rÀtt eller fel Àr en svÄr frÄga som hanteras olika vid olika belastningar. I Windows var schemalÀggaren fram till nyligen inriktad pÄ prioriterad bearbetning av skrivbordsapplikationer, vilket kunde leda till att bakgrundsprocesser hÀngde sig. I Sun Solaris fanns det fem olika klasser av schemalÀggare. NÀr virtualisering infördes lades den sjÀtte till, , eftersom de tidigare fem arbetade otillfredsstÀllande med virtualisering av Solaris Zones. Jag rekommenderar att du börjar en grundlig studie av detta Àmne med böcker som eller .
2.4. Hur övervakar man steal?
Att övervaka steal inom en virtuell maskin, precis som med vilken annan processor-metrik som helst, Ă€r enkelt: man kan anvĂ€nda vilket som helst verktyg för att hĂ€mta processor-metrik. Det viktigaste Ă€r att virtualmaskinen kör Linux. Windows tillhandahĂ„ller av nĂ„gon anledning inte sĂ„dan information för sina anvĂ€ndare. đ
Utdata frĂ„n kommandot top: detaljering av processorbelastning, i den allra högra kolumnen â steal
SvĂ„righeten uppstĂ„r nĂ€r man försöker fĂ„ denna information frĂ„n hypervisorn. Man kan försöka förutsĂ€ga steal pĂ„ vĂ€rdmaskinen, till exempel genom parametern Load Average (LA) â det genomsnittliga antalet processer som vĂ€ntar i kö för att köras. BerĂ€kningsmetoden för denna parameter Ă€r komplex, men generellt, om LA som normaliserats efter antal processorkĂ€rnor Ă€r större Ă€n 1, indikerar det att servern med Linux Ă€r överbelastad.
Vad vĂ€ntar alla dessa processer pĂ„? Det uppenbara svaret Ă€r processorn. Men svaret Ă€r inte helt korrekt, eftersom processorn ibland Ă€r ledig medan LA skjuter i höjden. TĂ€nk pĂ„, . PĂ„ samma sĂ€tt kan det vara med diskar och andra in- och utmatningsenheter. Men i verkligheten kan processer vĂ€nta pĂ„ avslutningen av vilken blockering som helst, bĂ„de fysisk, kopplad till in- och utmatningsenheter, och logisk, som mutexar. Det inkluderar Ă€ven blockeringar pĂ„ hĂ„rdvarunivĂ„ (samma svar frĂ„n disken) eller logiska (sĂ„ kallade blockeringsprimitive, som inkluderar en mĂ€ngd entiteter, mutexar av adaptiv typ och spin, semaforer, tillstĂ„ndsvariabler, rw-lĂ„s, ipc-lĂ„sâŠ).
En annan egenskap hos LA Àr att det berÀknas som ett genomsnitt över operativsystemet. Till exempel, om 100 processer tÀvlar om en fil, sÄ blir LA=50. Detta höga vÀrde tycks innebÀra att operativsystemet har problem. Men för annan felaktigt skriven kod kan detta vara ett normalt tillstÄnd, dÀr bara den koden pÄverkas, medan andra processer i operativsystemet inte pÄverkas.
PĂ„ grund av denna genomsnittning (som tar minst en minut), Ă€r det inte lĂ€tt att definiera nĂ„got baserat pĂ„ LA-vĂ€rdet, med ganska osĂ€kra resultat i specifika fall. Om du försöker förstĂ„ dig pĂ„ det, kommer du att upptĂ€cka att artiklar pĂ„ Wikipedia och andra tillgĂ€ngliga resurser endast beskriver de enklaste fallen, utan djupgĂ„ende förklaring av processen. Jag skickar alla intresserade, Ă„terigen,  â följ lĂ€nkarna. För de som inte orkar pĂ„ engelska â .
3. Specialeffekter
Nu stannar vi vid de huvudsakliga fallen av steal som vi har stött pÄ. Jag ska berÀtta hur de hÀrstammar frÄn allt ovanstÄende och hur de relaterar till mÄtten pÄ hypervisorn.
Ăverutnyttjande. Det mest grundlĂ€ggande och vanliga: hypervisorn Ă€r överutnyttjad. Det finns faktiskt mĂ„nga virtuella maskiner igĂ„ng, stort CPU-anvĂ€ndande inom dem, hög konkurrens, utnyttjande över LA över 1 (i normalisering efter CPU-trĂ„dar). Inuti alla virtuella maskiner stannar allt. Steal, vilket överförs frĂ„n hypervisorn, ökar ocksĂ„, det behövs omfördelning av belastningen eller att stĂ€nga av nĂ„gon. Sammanfattningsvis Ă€r allt logiskt och förstĂ„eligt.
Paravirtualisering mot ensamma instanser. PÄ hypervisorn finns en enda virtuell maskin som anvÀnder en liten del av resurserna, men den ger en stor belastning pÄ in- och utdata, exempelvis via disken. Och dÀr uppstÄr det lite steal, upp till 10 % (som flera genomförda experiment visar).
En intressant situation. Steal uppstÄr hÀr just pÄ grund av blockerade operationer pÄ nivÄn av para-virtualiserade drivrutiner. Inuti den virtuella maskinen skapas en avbrott, som drivrutinen hanterar och skickar till hypervisorn. PÄ grund av avbrottshanteringen pÄ hypervisorn ser det ut som att en begÀran har skickats för den virtuella maskinen; den Àr redo att utföra och vÀntar pÄ processorn, men fÄr ingen processortid. Den virtuella maskinen tror att denna tid har stulits.
Detta hÀnder i det ögonblick nÀr en buffert skickas, den gÄr in i kernel space pÄ hypervisorn, och vi börjar vÀnta. Ur den virtuella maskinens perspektiv borde den omedelbart ÄtervÀnda. Följaktligen betraktas denna tid som stulen enligt algoritmen för berÀkning av steal. Troligtvis kan det finnas andra mekanismer i denna situation (till exempel hantering av andra sys calls), men de bör inte skilja sig mycket.
SchemalÀggaren mot högbelastade virtuella maskiner. NÀr en virtuell maskin lider av mer steal Àn andra, ligger det just i schemalÀggaren. Ju mer processen belastar processorn, desto snabbare kommer schemalÀggaren att avbryta den för att ge andra möjlighet att arbeta. Om den virtuella maskinen förbrukar lite, kommer den knappt att mÀrka nÄgot steal: dess process satt pÄ ett hederligt sÀtt och vÀntade, den behöver mer tid. Om den virtuella maskinen producerar maximal belastning pÄ alla sina kÀrnor, avbryts den oftare frÄn processorn och fÄr inte mycket tid.
Det Àr Ànnu vÀrre nÀr processerna inom den virtuella maskinen försöker fÄ mer processortid eftersom de inte klarar av att bearbeta data. DÄ kommer operativsystemet pÄ hypervisorn, genom rÀttvis optimering, att ge allt mindre processortid. Denna process sker lavinartat, och steal skjuter i höjden, Àven om andra virtuella maskiner knappt mÀrker det. Ju fler kÀrnor, desto vÀrre för den drabbade maskinen. Kort sagt, det Àr högbelastade virtuella maskiner med mÄnga kÀrnor som lider mest.
LÄg LA, men det finns steal. Om LA ligger runt 0,7 (det vill sÀga att hypervisorn verkar vara underbelastad), men inom vissa virtuella maskiner observeras steal:
- Den redan beskrivna varianten med para-virtualisering. Virtuella maskiner kan fÄ mÀtvÀrden som indikerar stöld, Àven om hypervisorn fungerar bra. Enligt vÄra experiment överstiger sÄdan stöld inte 10 % och bör inte ha nÄgon betydande inverkan pÄ applikationernas prestanda inuti den virtuella maskinen.
- Parameter LA anses felaktigt. Mer exakt, i varje specifikt ögonblick berÀknas den korrekt, men nÀr den genomsnittas över en minut blir resultatet lÄgt. Till exempel, om en virtuell maskin under en halv minut anvÀnder alla sina processorer exakt, blir LA pÄ hypervisorn 0,15; fyra sÄdana virtuella maskiner som körs samtidigt ger 0,6. Men att det under en halv minut pÄ var och en av dem fanns en stor stöld pÄ 25 % enligt LA, gÄr inte att fÄnga.
- à terigen, pÄ grund av schemalÀggaren som beslutat att nÄgon Àter för mycket, och att den personen fÄr vÀnta. Under tiden vÀxlar jag kontext, hanterar avbrott och tar hand om andra viktiga systemuppgifter. Som ett resultat ser vissa virtuella maskiner inga problem, medan andra upplever allvarlig nedgradering av prestanda.
4. Andra förvrÀngningar
Det finns minst en miljon orsaker till förvrÀngningar av det rÀttvisa processorutnyttjandet pÄ en virtuell maskin. Till exempel bidrar hyper-threading och NUMA till svÄrigheter i berÀkningarna. De förvirrar helt val av kÀrna för processexekvering, eftersom schemalÀggaren anvÀnder koefficienter - vikter, som vid kontextbyten gör berÀkningen Ànnu mer komplicerad.
FörvrÀngningar kan ocksÄ uppstÄ pÄ grund av teknologier som turboboost eller, Ä andra sidan, energibesparande lÀgen, som vid berÀkning av utnyttjande artificiellt kan höja eller sÀnka frekvensen eller till och med tidskvantiteten pÄ servern. Aktivering av turboboost minskar prestandan för en processortrÄd pÄ grund av ökad prestanda för en annan. Vid den tidpunkten överförs inte information om den aktuella processor-frekvensen till den virtuella maskinen, och den tror att nÄgon stjÀl dess tid (till exempel begÀrde den 2 GHz men fick hÀlften sÄ lite).
Kort sagt, det kan finnas mÄnga orsaker till förvrÀngningar. I ett specifikt system kan du upptÀcka nÄgot annat. BÀttre att börja med böckerna jag lÀnkade till ovan och samla statistik frÄn hypervisorn med verktyg som perf, sysdig, systemtap, som det finns .
5. Slutsatser
- Ett visst antal steal kan uppstÄ pÄ grund av paravirtualisering och anses normalt. PÄ internet skriver de att detta vÀrde kan vara mellan 5-10 %. Det beror pÄ applikationerna inuti virtuella maskiner och den belastning de lÀgger pÄ sina fysiska enheter. Det Àr viktigt att uppmÀrksamma hur applikationerna mÄr inuti de virtuella maskinerna.
- FörhÄllandet mellan belastningen pÄ hypervisorn och steal inuti den virtuella maskinen Àr inte alltid entydigt relaterade, bÄda bedömningar av steal kan vara felaktiga i specifika situationer med olika belastningar.
- SchemalÀggaren har en negativ instÀllning till processer som begÀr mycket. Den försöker ge mindre till dem som ber mer. Stora virtuella maskiner Àr ett problem.
- Ett litet steal kan vara normalt Àven utan paravirtualisering (med tanke pÄ belastningen inuti den virtuella maskinen, egenskaperna hos grannarnas belastning, fördelningen av belastningen över trÄdar och andra faktorer).
- Om du vill ta reda pÄ steal i ett specifikt system mÄste du undersöka olika alternativ, samla in metrik, noggrant analysera dem och fundera pÄ hur man fördelar belastningen jÀmnt. Det kan finnas avvikelser frÄn alla fall som mÄste bekrÀftas experimentelet eller ses i kÀrnans debugger.
KĂ€lla: habr.com
