{"id":32331,"date":"2019-10-31T21:46:24","date_gmt":"2019-10-31T18:46:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\/"},"modified":"2019-10-31T21:46:24","modified_gmt":"2019-10-31T18:46:24","slug":"steal-kto-kradyot-u-virtualok-protsessornoe-vremya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","title":{"rendered":"Steal: chi ruba il tempo di CPU delle macchine virtuali","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Steal: chi ruba il tempo di CPU delle macchine virtuali\" src=\"\/wp-content\/uploads\/2019\/04\/23cac5d3cc3295dc6f1014e9fda36b89.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCiao! Voglio spiegare in modo semplice la meccanica della comparsa dello steal all'interno delle macchine virtuali e alcuni artefatti non immediatamente evidenti che siamo riusciti a scoprire durante la nostra ricerca, in cui sono dovuto immergermi come CTO della piattaforma cloud. <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Mail.ru Cloud Solutions<\/a><\/noindex>. La piattaforma funziona su KVM.<\/p>\n<p>Il tempo di CPU steal \u00e8 il periodo in cui la macchina virtuale non riceve risorse della CPU necessarie per la sua esecuzione. Questo tempo \u00e8 considerato solo nei sistemi operativi guest negli ambienti di virtualizzazione. Le ragioni per cui queste risorse allocate sembrano scomparire sono, come nella vita reale, piuttosto oscure. Ma abbiamo deciso di indagare, e abbiamo persino condotto una serie di esperimenti. Non \u00e8 che ora sappiamo tutto sullo steal, ma abbiamo alcune informazioni interessanti da condividere.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>1. Cos'\u00e8 lo steal<\/h2>\n<p>\nQuindi, lo steal \u00e8 una metrica che indica la carenza di tempo di CPU per i processi all'interno della macchina virtuale. Come descritto <noindex><a rel=\"nofollow\" href=\"https:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/stable\/linux.git\/patch\/?id=c9aaa8957f203bd6df83b002fb40b98390bed078\">nel patch del kernel KVM<\/a><\/noindex>, steal \u2014 \u00e8 il tempo durante il quale l'hypervisor esegue altri processi sul sistema operativo host, mentre ha messo il processo della macchina virtuale in coda per l'esecuzione. In altre parole, il tempo di steal \u00e8 considerato come la differenza tra il momento in cui il processo \u00e8 pronto per essere eseguito e il momento in cui gli viene assegnato del tempo di CPU.<\/p>\n<p>La metrica di steal viene ricevuta dalla macchina virtuale dall'hypervisor. Tuttavia, l'hypervisor non specifica quali altri processi sta eseguendo, semplicemente \u00abmentre sono occupato, non posso dedicarti tempo\u00bb. Nel KVM, il supporto per il conteggio dello steal \u00e8 stato aggiunto nei <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/449657\/\">patch<\/a><\/noindex>. Ci sono due punti chiave qui: <\/p>\n<ul>\n<li>La macchina virtuale apprende dello steal dall'hypervisor. Cio\u00e8, dal punto di vista delle perdite, per i processi sulla stessa virtual machine si tratta di una misura indiretta, che pu\u00f2 essere soggetta a varie distorsioni.\n<\/li>\n<li>L'hypervisor non condivide con la macchina virtuale le informazioni su cosa stia facendo di altro \u2014 l'importante \u00e8 che non le dedichi tempo. A causa di ci\u00f2, la stessa macchina virtuale non pu\u00f2 rilevare le distorsioni nel valore dello steal, che potrebbero essere valutate in base alla natura dei processi concorrenti.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Cosa influisce sullo steal<\/h2>\n<p><\/p>\n<h3>2.1. Calcolo dello steal<\/h3>\n<p>\nIn sostanza, il termine \"steal\" viene considerato quasi allo stesso modo del normale utilizzo della CPU. Non ci sono molte informazioni su come venga calcolato l'utilizzo. Probabilmente perch\u00e9 la maggior parte delle persone considera questa questione ovvia. Ma ci sono anche degli insidiosi dettagli. Per approfondire questo processo, puoi leggere <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-05-09\/cpu-utilization-is-wrong.html\">l'articolo di Brendann Gregg<\/a><\/noindex>: scoprirai molte sfumature nel calcolo dell'utilizzo e le situazioni in cui questo conteggio potrebbe essere errato per i seguenti motivi:<\/p>\n<ul>\n<li>Surriscaldamento della CPU, durante il quale si saltano dei cicli.\n<\/li>\n<li>Attivazione\/disattivazione del turbo boost, che comporta una modifica della frequenza di clock della CPU.\n<\/li>\n<li>Variazione della durata del quantum di tempo, che avviene quando si utilizzano tecnologie di risparmio energetico della CPU, come SpeedStep.\n<\/li>\n<li>Il problema del calcolo della media: una stima dell'utilizzo dell'80% in un minuto pu\u00f2 nascondere un picco temporaneo del 100%.\n<\/li>\n<li>Il blocco ciclico (spin lock) porta a una situazione in cui il processore \u00e8 utilizzato, ma il processo dell'utente non mostra progressi nell'esecuzione. Di conseguenza, l'utilizzo calcolato del processore da parte del processo sar\u00e0 del cento percento, anche se fisicamente il tempo di utilizzo del processore non sar\u00e0 consumato dal processo.\n<\/li>\n<\/ul>\n<p>\nNon ho trovato articoli che descrivano un conteggio simile per il steal (se ne conoscete, condivideteli nei commenti). Ma, a giudicare dal codice sorgente, il meccanismo di calcolo \u00e8 lo stesso di quello per l'utilizzo. Viene semplicemente aggiunto un altro contatore nel kernel, specificamente per il processo KVM (il processo della macchina virtuale), che calcola la durata della permanenza del processo KVM in attesa del tempo di processore. Il contatore raccoglie informazioni sul processore dalle sue specifiche e verifica se tutti i suoi tick sono stati utilizzati dal processo virtuale. Se tutti lo sono, consideriamo che il processore \u00e8 stato impegnato solo con il processo della macchina virtuale. In caso contrario, informiamo che il processore \u00e8 stato impegnato in qualcos'altro, \u00e8 apparso il steal. <\/p>\n<p>Il processo di conteggio dello steal \u00e8 soggetto agli stessi problemi del normale conteggio dell'utilizzo. Non si pu\u00f2 dire che questi problemi si verifichino frequentemente, ma sono sicuramente scoraggianti.<\/p>\n<h3>2.2. Tipi di virtualizzazione su KVM<\/h3>\n<p>\nIn generale, ci sono tre tipi di virtualizzazione, tutti supportati da KVM. Il tipo di virtualizzazione pu\u00f2 influenzare il meccanismo di generazione dello steal.<\/p>\n<p><b>Traduzione<\/b>. In questo caso, il funzionamento del sistema operativo della macchina virtuale con i dispositivi fisici dell'iperdispositore avviene pi\u00f9 o meno in questo modo:<\/p>\n<ol>\n<li>Il sistema operativo guest invia un comando al suo dispositivo guest.\n<\/li>\n<li>Il driver del dispositivo guest riceve il comando, elabora una richiesta per il BIOS del dispositivo e la invia all'iperdispositore.\n<\/li>\n<li>Il processo dell'iperdispositore traduce il comando in un comando per il dispositivo fisico, rendendolo, tra l'altro, pi\u00f9 sicuro.\n<\/li>\n<li>Il driver del dispositivo fisico riceve il comando modificato e lo invia al dispositivo fisico stesso.\n<\/li>\n<li>I risultati dell'esecuzione dei comandi tornano indietro lungo lo stesso percorso. \n<\/li>\n<\/ol>\n<p>\nIl vantaggio della virtualizzazione \u00e8 che consente di emulare qualsiasi dispositivo senza necessitare di una preparazione specifica del kernel del sistema operativo. Tuttavia, questo comporta un sacrificio, soprattutto in termini di prestazioni. <\/p>\n<p><b>Virtualizzazione hardware<\/b>. In questo caso, il dispositivo comprende a livello hardware i comandi provenienti dal sistema operativo. Questo \u00e8 il metodo pi\u00f9 veloce e efficace. Sfortunatamente, per\u00f2, non \u00e8 supportato da tutti i dispositivi fisici, hypervisor e sistemi operativi guest. Al momento, i principali dispositivi che supportano la virtualizzazione hardware sono le CPU.<\/p>\n<p><b>Paravirtualizzazione<\/b>. La modalit\u00e0 di virtualizzazione pi\u00f9 comune su KVM e, in generale, la pi\u00f9 diffusa per i sistemi operativi guest. La sua caratteristica principale \u00e8 che l'interazione con alcuni sottosistemi dell'ipervisor (ad esempio, con lo stack di rete o disco) o l'allocazione delle pagine di memoria avviene tramite le API dell'ipervisor, senza la traduzione di comandi a basso livello. Lo svantaggio di questo metodo di virtualizzazione \u00e8 la necessit\u00e0 di modificare il kernel del sistema operativo guest affinch\u00e9 possa interagire con l'ipervisor attraverso queste API. Tuttavia, solitamente ci\u00f2 si risolve installando driver speciali sul sistema operativo guest. In KVM, questa API \u00e8 chiamata <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/developerworks\/library\/l-virtio\/index.html\">virtio API<\/a><\/noindex>.<\/p>\n<p>Con la paravirtualizzazione, rispetto alla traslazione, il percorso verso il dispositivo fisico si riduce significativamente grazie all'invio diretto dei comandi dalla macchina virtuale al processo dell'ipervisor sull'host. Questo consente di accelerare l'esecuzione di tutte le istruzioni all'interno della macchina virtuale. In KVM, ci\u00f2 \u00e8 gestito dall'API virtio, che funziona solo per determinati dispositivi, come l'adattatore di rete o il disco. \u00c8 per questo che all'interno delle macchine virtuali vengono installati i driver virtio. <\/p>\n<p>L'ombra di tale accelerazione \u00e8 che non tutti i processi eseguiti all'interno della macchina virtuale rimangono al suo interno. Questo crea alcuni effetti collaterali che possono portare alla comparsa di steal. Consiglio di iniziare un'analisi approfondita di questo tema con <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/239238\/\">Un API per l'I\/O virtuale: virtio<\/a><\/noindex>.<\/p>\n<h3>2.3. Scheduling 'equo'<\/h3>\n<p>\nLa macchina virtuale sull'ipervisor \u00e8, di fatto, un processo normale, che \u00e8 soggetto alle regole di scheduling (distribuzione delle risorse tra i processi) del kernel Linux, quindi esaminiamola pi\u00f9 in dettaglio. <\/p>\n<p>In Linux si utilizza il cosiddetto CFS, Completely Fair Scheduler, che \u00e8 diventato il gestore predefinito a partire dal kernel 2.6.23. Per comprendere questo algoritmo, \u00e8 possibile leggere il Linux Kernel Architecture o i suoi sorgenti. L'essenza del CFS consiste nella distribuzione del tempo di CPU tra i processi in base alla durata della loro esecuzione. Maggiore \u00e8 il tempo di CPU richiesto da un processo, minore sar\u00e0 il tempo che ricever\u00e0. Questo garantisce un'esecuzione \"equilibrata\" di tutti i processi, in modo che un singolo processo non monopolizzi continuamente tutte le CPU, e gli altri processi possano anche essere eseguiti. <\/p>\n<p>Talvolta questa paradigma porta a interessanti artefatti. I veterani di Linux ricorderanno sicuramente il congelamento di un normale editor di testo sul desktop durante l'avvio di applicazioni pesanti come un compilatore. Ci\u00f2 accadeva perch\u00e9 i compiti leggeri delle applicazioni desktop competevano con quelli che consumavano attivamente risorse, come il compilatore. Il CFS considera questo ingiusto, quindi interrompe periodicamente l'editor di testo e permette alla CPU di elaborare i compiti del compilatore. Questo \u00e8 stato risolto grazie a un meccanismo <noindex><a rel=\"nofollow\" href=\"https:\/\/marc.info\/?l=linux-kernel&amp;m=128978361700898\">sched_autogroup<\/a><\/noindex>, ma ci sono ancora molte altre caratteristiche della distribuzione del tempo di CPU tra le attivit\u00e0. In effetti, non si tratta di come tutto sia problematico in CFS, ma \u00e8 un tentativo di attirare l'attenzione sul fatto che una distribuzione \"equa\" del tempo di CPU non \u00e8 una questione banale.<\/p>\n<p>Un altro punto importante nel pianificatore \u00e8 la preemption. Questo \u00e8 necessario per espellere un processo affamato dalla CPU e dare l'opportunit\u00e0 di lavorare ad altri. Il processo di espulsione \u00e8 chiamato context switching, lo switching del contesto della CPU. Durante questo processo, tutto il contesto del task viene salvato: lo stato dello stack, i registri e altro, dopodich\u00e9 il processo viene messo in attesa e un altro prende il suo posto. Questa \u00e8 un'operazione costosa per il sistema operativo e viene utilizzata raramente, ma in sostanza non c'\u00e8 niente di male. Un frequente switching del contesto pu\u00f2 indicare un problema nel sistema operativo, ma di solito avviene in modo continuo e non indica nulla di particolare.<\/p>\n<p>Una storia cos\u00ec lunga \u00e8 necessaria per spiegare un fatto: pi\u00f9 risorse della CPU un processo cerca di utilizzare in uno scheduler Linux onesto, pi\u00f9 velocemente verr\u00e0 fermato, affinch\u00e9 anche altri processi possano lavorare. Se ci\u00f2 sia corretto o meno \u00e8 una questione complessa che varia in base ai diversi carichi. In Windows, fino a poco tempo fa, lo scheduler era orientato alla gestione prioritaria delle applicazioni desktop, il che poteva generare blocchi nei processi in background. In Sun Solaris c'erano cinque classi diverse di scheduler. Con l'introduzione della virtualizzazione \u00e8 stato aggiunto un sesto, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opennet.ru\/man.shtml?topic=FSS&amp;category=7&amp;russian=4\">Fair share scheduler<\/a><\/noindex>, poich\u00e9 i cinque precedenti non funzionavano adeguatamente con la virtualizzazione di Solaris Zones. Consiglio di iniziare un approfondimento su questo argomento con libri come <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Solaris-Internals-OpenSolaris-Kernel-Architecture\/dp\/0131482092\/\">Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture<\/a><\/noindex> o <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Understanding-Linux-Kernel-Third-Daniel\/dp\/0596005652\/\">Understanding the Linux Kernel<\/a><\/noindex>.<\/p>\n<h3>2.4. Come monitorare il steal?<\/h3>\n<p>\nMonitorare il steal all'interno di una macchina virtuale, come qualsiasi altra metrica della CPU, \u00e8 semplice: si pu\u00f2 utilizzare qualsiasi strumento di raccolta metriche della CPU. L'importante \u00e8 che la virtual machine sia su Linux. Per qualche motivo, Windows non fornisce queste informazioni ai suoi utenti. \ud83d\ude41<\/p>\n<p><img decoding=\"async\" alt=\"Steal: chi ruba il tempo di CPU delle macchine virtuali\" src=\"\/wp-content\/uploads\/2019\/04\/3c7cd04f73fd6a74b86af81382090b69.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Output del comando top: dettaglio del carico sulla CPU, nell'ultima colonna a destra \u2014 steal<\/i><\/p>\n<p>La difficolt\u00e0 sorge quando si cerca di ottenere queste informazioni dal hypervisor. Si pu\u00f2 provare a stimare lo steal sulla machine host, ad esempio, attraverso il parametro Load Average (LA) \u2014 il valore medio dei processi in attesa nella coda di esecuzione. Il metodo di calcolo di questo parametro non \u00e8 semplice, ma in generale, se il LA normalizzato rispetto al numero di thread della CPU \u00e8 superiore a 1, ci\u00f2 indica che il server Linux \u00e8 sovraccarico. <\/p>\n<p>Cosa stanno aspettando tutti questi processi? La risposta ovvia \u00e8 \u2014 la CPU. Ma la risposta non \u00e8 del tutto corretta, poich\u00e9 a volte la CPU \u00e8 libera, ma il LA \u00e8 alle stelle. Ricordate, <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/911976\/redhat-nfs-cluster-high-load-average-suddenly\">come fallisce l'NFS e come aumenta il LA<\/a><\/noindex>. Allo stesso modo pu\u00f2 accadere anche con il disco e altri dispositivi di input\/output. In realt\u00e0, i processi possono attendere la fine di qualsiasi tipo di blocco, fisico, legato al dispositivo di input\/output, o logico, come i mutex. Ci sono anche i blocchi a livello hardware (ad esempio, la risposta del disco) o logica (i cosiddetti primitivi di blocco, che includono diverse entit\u00e0, mutex adattivi e spin, semaphore, variabili di condizione, rw locks, ipc locks\u2026).<\/p>\n<p>Un'altra caratteristica della LA \u00e8 che viene considerata come una media nel sistema operativo. Ad esempio, se 100 processi competono per un file, allora LA=50. Un valore cos\u00ec elevato potrebbe far sembrare che il sistema operativo stia male. Tuttavia, per un codice mal scritto, questo pu\u00f2 essere uno stato normale, in cui solo quel codice presenta problemi, mentre gli altri processi nel sistema operativo non ne risentono. <\/p>\n<p>A causa di questa mediazione (che richiede almeno un minuto), cercare di definire qualcosa utilizzando il parametro LA non \u00e8 l'impresa pi\u00f9 gratificante, con risultati piuttosto incerti in casi specifici. Se provate a fare chiarezza, scoprirete che negli articoli di Wikipedia e in altre risorse disponibili sono descritti solo i casi pi\u00f9 semplici, senza una spiegazione approfondita del processo. Rimando tutti gli interessati, ancora una volta, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-08-08\/linux-load-averages.html\">qui, da Brendann Gregg<\/a><\/noindex> \u00a0\u2014 nei collegamenti successivi. Chi non ha voglia di leggere in inglese \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/335326\/\">la traduzione del suo articolo popolare su LA<\/a><\/noindex>.<\/p>\n<h2>3. Effetti speciali<\/h2>\n<p>\nOra ci concentreremo sui principali casi di apparizione di steal, con cui abbiamo a che fare. Vi dir\u00f2 come derivano da quanto detto sopra e come si relazionano ai parametri del hypervisor.<\/p>\n<p><b>Riutilizzazione<\/b>. La cosa pi\u00f9 semplice e comune: l'hypervisor \u00e8 sovraccarico. In effetti, ci sono molte macchine virtuali in esecuzione, un alto consumo di CPU e una notevole competizione, con un utilizzo superiore a 1 in base ai thread della CPU. All'interno di tutte le macchine virtuali, tutto rallenta. Lo steal, trasmesso dall'hypervisor, aumenta anche; \u00e8 necessario ridistribuire il carico o spegnere qualcuno. In generale, \u00e8 tutto logico e chiaro.<\/p>\n<p><b>Paravirtualizzazione contro istanze singole<\/b>. Sull'hypervisor c'\u00e8 una sola macchina virtuale, che consuma una piccola parte di esso, ma impone un grande carico in termini di input\/output, ad esempio sul disco. E da qualche parte in essa appare un piccolo steal, fino al 10% (come mostrano alcuni esperimenti condotti).<\/p>\n<p>Un caso interessante. Steal appare proprio a causa dei blocchi a livello dei driver paravirtualizzati. All'interno della virtual machine viene generata un'interruzione, che viene gestita dal driver e inviata al hypervisor. A causa della gestione dell'interruzione nel hypervisor, per la virtual machine questo sembra come una richiesta inviata, \u00e8 pronta per essere eseguita e attende la CPU, ma non le viene data del tempo processore. La virtual machine pensa che questo tempo sia stato rubato. <\/p>\n<p>Questo avviene nel momento in cui il buffer viene inviato, entra nello spazio kernel del hypervisor e iniziamo ad attenderlo. Sebbene, dal punto di vista della virtual machine, dovrebbe tornare subito. Di conseguenza, secondo l'algoritmo di calcolo di steal, questo tempo \u00e8 considerato rubato. Probabilmente, in questa situazione potrebbero esserci anche altri meccanismi (ad esempio, l'elaborazione di alcune sys calls), ma non dovrebbero differire molto.<\/p>\n<p><b>Scheduler contro virtual machines ad alto carico<\/b>. Quando una macchina virtuale soffre di steal pi\u00f9 di altre, ci\u00f2 \u00e8 legato proprio al pianificatore. Pi\u00f9 intensamente un processo carica la CPU, pi\u00f9 velocemente il pianificatore lo espelle per permettere anche agli altri di lavorare. Se una macchina virtuale consuma poco, non noter\u00e0 quasi il steal: il suo processo ha onestamente atteso e ha bisogno di pi\u00f9 tempo. Se una macchina virtuale produce un carico massimo su tutti i suoi core, verr\u00e0 espulsa pi\u00f9 spesso dalla CPU e si cercher\u00e0 di non darle troppo tempo. <\/p>\n<p>Ancora peggio \u00e8 quando i processi all'interno della macchina virtuale cercano di ottenere pi\u00f9 CPU, perch\u00e9 non riescono a elaborare i dati. Allora il sistema operativo sul hypervisor, grazie a un'ottimizzazione onesta, assegner\u00e0 sempre meno tempo di CPU. Questo processo avviene in modo esponenziale, e il steal schizza alle stelle, anche se le altre macchine virtuali possono quasi non notarlo. E pi\u00f9 core ci sono, peggio sar\u00e0 per la macchina colpita. In sintesi, soffrono di pi\u00f9 le macchine virtuali ad alto carico con numerosi core.<\/p>\n<p><b>Basso LA, ma c'\u00e8 steal<\/b>. Se il LA \u00e8 circa 0,7 (cio\u00e8, l'hypervisor sembra non essere sovraccarico), ma all'interno di singole macchine virtuali si osserva lo steal:<\/p>\n<ul>\n<li>La variante di paravirtualizzazione gi\u00e0 descritta sopra. La macchina virtuale pu\u00f2 ricevere metriche che indicano lo steal, anche se l'hypervisor \u00e8 a posto. Dai risultati dei nostri esperimenti, questa forma di steal non supera il 10% e non dovrebbe avere un impatto significativo sulle prestazioni delle applicazioni all'interno della macchina virtuale.\n<\/li>\n<li>Il parametro LA \u00e8 calcolato in modo errato. Pi\u00f9 precisamente, in ogni momento specifico viene calcolato correttamente, ma l'averlo mediato su un minuto risulta sottovalutato. Ad esempio, se una macchina virtuale consuma tutti i suoi processori per esattamente mezzo minuto su un terzo dell'hypervisor, il LA dell'hypervisor per un minuto sar\u00e0 0,15; quattro di queste macchine virtuali che lavorano simultaneamente daranno 0,6. E il fatto che per mezzo minuto ciascuna di esse ha avuto uno steal estremo del 25% non pu\u00f2 essere recuperato.\n<\/li>\n<li>Ancora una volta, a causa dello scheduler che ha deciso che qualcuno stava consumando troppe risorse, e che quel qualcuno deve aspettare. Nel frattempo, cambio il contesto, gestisco le interruzioni e mi occupo di altre importanti attivit\u00e0 di sistema. Alla fine, alcune macchine virtuali non riscontrano problemi, mentre altre subiscono una grave degradazione delle prestazioni.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>4. Altri disturbi<\/h2>\n<p>\nCi sono anche un milione di altre ragioni per le distorsioni nella giusta assegnazione del tempo di CPU in una macchina virtuale. Ad esempio, il hyper-threading e il NUMA complicano ulteriormente i calcoli. Questi confondono completamente la scelta del core per l'esecuzione del processo, poich\u00e9 lo scheduler utilizza coefficienti \u2014 pesi che rendono il conteggio ancora pi\u00f9 complicato durante il cambio di contesto.<\/p>\n<p>Possono verificarsi distorsioni a causa di tecnologie come il turbo boost o, al contrario, della modalit\u00e0 di risparmio energetico, che possono alterare artificialmente la frequenza o anche il quantum di tempo su un server durante il calcolo della sua utilizzazione. L'attivazione del turbo boost riduce le prestazioni di un thread di CPU a causa dell'aumento delle prestazioni di un altro. In quel momento, le informazioni sulla frequenza attuale del processore non vengono trasferite alla macchina virtuale, che crede che il suo tempo venga rubato (ad esempio, se chiedeva 2 GHz ma ne riceve solo la met\u00e0). <\/p>\n<p>In generale, ci possono essere molte cause di distorsione. In un sistema specifico, potresti scoprire qualcos'altro. \u00c8 meglio iniziare con i libri ai quali ho fornito i link sopra e raccogliere statistiche dall'iper-vizore utilizzando strumenti come perf, sysdig, systemtap, ce ne sono <noindex><a rel=\"nofollow\" href=\"https:\/\/jvns.ca\/blog\/2017\/07\/05\/linux-tracing-systems\/\">decine<\/a><\/noindex>.<\/p>\n<h2>5. Conclusioni<\/h2>\n<p><\/p>\n<ol>\n<li>Un certo livello di steal pu\u00f2 verificarsi a causa della paravirtualizzazione ed \u00e8 considerato normale. Si legge online che questo valore pu\u00f2 raggiungere il 5-10%. Dipende dalle applicazioni all'interno della virtual machine e dal carico che esse impongono sulle proprie risorse fisiche. \u00c8 importante prestare attenzione a come si comportano le applicazioni all'interno delle virtual machine.\n<\/li>\n<li>Il rapporto di carico sul hypervisor e lo steal all'interno della virtual machine non sono sempre chiaramente correlati; entrambe le stime dello steal possono risultare errate in situazioni specifiche con carichi diversi.\n<\/li>\n<li>Il scheduler tende a penalizzare i processi che effettuano molte richieste. Cerca di dare meno risorse a chi richiede di pi\u00f9. Grandi virtual machine sono problematiche.\n<\/li>\n<li>Un piccolo steal pu\u00f2 essere nella norma anche senza paravirtualizzazione (considerando il carico all'interno della virtual machine, le caratteristiche del carico dei vicini, la distribuzione del carico sui thread e altri fattori).\n<\/li>\n<li>Se desideri capire il phenomenon dello steal in un sistema specifico, devi esplorare diverse opzioni, raccogliere metriche, analizzarle attentamente e pianificare come distribuire uniformemente il carico. Ci possono essere deviazioni da qualsiasi caso che devono essere confermate sperimentalmente o osservate nel debugger del kernel.\n<\/li>\n<\/ol>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/449316\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442! \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e\u0441\u0442\u044b\u043c \u044f\u0437\u044b\u043a\u043e\u043c \u043e \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0435 \u0432\u043e\u0437\u043d\u0438\u043a\u043d\u043e\u0432\u0435\u043d\u0438\u044f steal \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0438 \u043e \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043d\u0435\u043e\u0447\u0435\u0432\u0438\u0434\u043d\u044b\u0445 \u0430\u0440\u0442\u0435\u0444\u0430\u043a\u0442\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0430\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u0432\u044b\u044f\u0441\u043d\u0438\u0442\u044c \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0438, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u043c\u043d\u0435 \u043f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u043f\u043e\u0433\u0440\u0443\u0437\u0438\u0442\u044c\u0441\u044f \u043a\u0430\u043a \u0442\u0435\u0445\u0434\u0438\u0440\u0443 \u043e\u0431\u043b\u0430\u0447\u043d\u043e\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Mail.ru Cloud Solutions. \u041f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043d\u0430 KVM. CPU steal time \u2014 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f, \u0432 \u0442\u0435\u0447\u0435\u043d\u0438\u0435 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0430\u044f \u043c\u0430\u0448\u0438\u043d\u0430 \u043d\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442 \u0440\u0435\u0441\u0443\u0440\u0441\u044b \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24147,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32331","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Steal: \u043a\u0442\u043e \u043a\u0440\u0430\u0434\u0451\u0442 \u0443 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u043e\u043a \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:46:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:46:24+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Steal: chi ruba tempo di CPU alle macchine virtuali | ProHoster","description":"Ciao!","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Steal: \u043a\u0442\u043e \u043a\u0440\u0430\u0434\u0451\u0442 \u0443 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u043e\u043a \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442!","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:46:24+00:00","article:modified_time":"2019-10-31T18:46:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32331","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 10:21:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:00:23","updated":"2026-01-21 10:21:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/32331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=32331"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/32331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/24147"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=32331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=32331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=32331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}