{"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":"Ruba: chi ruba tempo di CPU dalle macchine virtuali","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Ruba: chi ruba tempo di CPU dalle 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 generazione di steal all'interno delle macchine virtuali e alcuni artefatti non ovvi che siamo riusciti a scoprire durante la sua ricerca, nella quale sono dovuto immergermi come dirigente tecnico 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 tempo durante il quale la macchina virtuale non riceve risorse di elaborazione per la sua esecuzione. Questo tempo \u00e8 considerato solo nei sistemi operativi guest in ambienti di virtualizzazione. Le ragioni per cui queste risorse allocate scompaiono, come nella vita, sono piuttosto oscure. Ma abbiamo deciso di approfondire la questione, e abbiamo persino condotto una serie di esperimenti. Non \u00e8 che ora sappiamo tutto sullo steal, ma vi racconteremo qualcosa di interessante.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>1. Che cos'\u00e8 lo steal<\/h2>\n<p>\nQuindi, lo steal \u00e8 una metrica che indica la scarsit\u00e0 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>, lo steal \u00e8 il tempo durante il quale l'ipercontrollore esegue altri processi sul sistema operativo host, anche se ha messo il processo della macchina virtuale in coda per l'esecuzione. Quindi, lo steal \u00e8 calcolato come la differenza tra il tempo in cui il processo \u00e8 pronto per essere eseguito e il momento in cui viene allocato il tempo di CPU.<\/p>\n<p>La metrica di steal \u00e8 fornita dal hypervisor alla macchina virtuale. Tuttavia, l'ipercontrollore non specifica quali altri processi sta eseguendo, semplicemente dice \"mentre sono occupato, non posso dedicarvi del tempo\". Su KVM, il supporto per il calcolo dello steal \u00e8 stato aggiunto nei <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/449657\/\">patch<\/a><\/noindex>. Qui ci sono due punti chiave: <\/p>\n<ul>\n<li>La macchina virtuale apprende il valore di steal dall'ipercontrollore. Quindi, dal punto di vista delle perdite, per i processi sulla macchina virtuale stessa, \u00e8 una misura indiretta che pu\u00f2 essere soggetta a varie distorsioni.\n<\/li>\n<li>L'ipercontrollore non condivide con la macchina virtuale informazioni su quello con cui \u00e8 impegnato \u2014 l'importante \u00e8 che non le stia dedicando tempo. Per questo motivo, la macchina virtuale stessa non riesce a identificare le distorsioni nel valore di steal, che potrebbero essere valutate in base alla natura dei processi concorrenti.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Cosa influenza lo steal<\/h2>\n<p><\/p>\n<h3>2.1. Calcolo dello steal<\/h3>\n<p>\nEssenzialmente, il calcolo dello steal avviene in modo simile al normale tempo di utilizzo della CPU. Non ci sono molte informazioni su come si calcola l'utilizzo, forse perch\u00e9 la maggior parte delle persone considera questo aspetto ovvio. Ma anche qui ci sono delle insidie. Per conoscere meglio questo processo, \u00e8 possibile leggere <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-05-09\/cpu-utilization-is-wrong.html\">articolo di Brendann Gregg<\/a><\/noindex>: scoprirai una serie di sfumature nel calcolo dell'utilizzo e situazioni in cui questo calcolo potrebbe risultare errato per i seguenti motivi:<\/p>\n<ul>\n<li>Surriscaldamento della CPU, durante il quale vengono persi i tick.\n<\/li>\n<li>Attivazione\/disattivazione del turbo boost, a causa della quale cambia la frequenza di clock della CPU.\n<\/li>\n<li>Modifica della durata del quant di tempo, che si verifica quando si utilizzano tecnologie di risparmio energetico della CPU, come SpeedStep.\n<\/li>\n<li>Problema nel 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) provoca un utilizzo della CPU, ma il processo dell'utente non vede progressi nella sua esecuzione. Di conseguenza, l'utilizzo stimato della CPU sar\u00e0 del 100 %, anche se fisicamente il tempo della CPU non sar\u00e0 consumato dal processo.\n<\/li>\n<\/ul>\n<p>\nNon ho trovato articoli che descrivano simili calcoli per lo steal (se li conoscete - condividete nei commenti). Tuttavia, a giudicare dai codici sorgente, il meccanismo di calcolo \u00e8 lo stesso di quello per l'utilizzo. Semplicemente nel kernel viene aggiunto un ulteriore contatore, specificamente per il processo KVM (il processo della macchina virtuale), che calcola la durata della permanenza del processo KVM in attesa di tempo di CPU. Il contatore prende informazioni sulla CPU dalle sue specifiche e verifica se tutti i suoi tick sono stati utilizzati dal processo della macchina virtuale. Se lo sono stati, consideriamo che la CPU \u00e8 stata impegnata solo nel processo della macchina virtuale. In caso contrario, informiamo che la CPU \u00e8 stata occupata da qualcos'altro, \u00e8 apparso lo steal. <\/p>\n<p>Il processo di calcolo dello steal \u00e8 soggetto agli stessi problemi del calcolo dell'utilizzo normale. Non si pu\u00f2 dire che questi problemi si verifichino frequentemente, ma sembrano scoraggianti.<\/p>\n<h3>2.2. Tipi di virtualizzazione su KVM<\/h3>\n<p>\nIn generale, ci sono tre tipi di virtualizzazione, e tutti sono supportati da KVM. Il tipo di virtualizzazione pu\u00f2 influenzare il meccanismo di insorgenza dello steal.<\/p>\n<p><b>Trasmissione<\/b>. In questo caso, il lavoro del sistema operativo della macchina virtuale con i dispositivi fisici dell'ipervisor avviene approssimativamente in questo modo:<\/p>\n<ol>\n<li>Il sistema operativo guest invia al proprio dispositivo guest un comando.\n<\/li>\n<li>Il driver del dispositivo guest riceve il comando, forma una richiesta per il BIOS del dispositivo e la invia all'ipervisor.\n<\/li>\n<li>Il processo dell'ipervisore 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 gi\u00e0 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 traduzione \u00e8 che consente di emulare qualsiasi dispositivo e non richiede una preparazione speciale del kernel del sistema operativo. Ma per questo si paga, soprattutto, in termini di prestazioni. <\/p>\n<p><b>Virtualizzazione hardware<\/b>. In questo caso, il dispositivo a livello hardware comprende i comandi dal sistema operativo. Questo \u00e8 il modo pi\u00f9 veloce e migliore. Ma, sfortunatamente, non \u00e8 supportato da tutti i dispositivi fisici, ipervisori e sistemi operativi guest. Attualmente, i principali dispositivi che supportano la virtualizzazione hardware sono i processori.<\/p>\n<p><b>Paravirtualizzazione<\/b>. La variante di virtualizzazione dei dispositivi pi\u00f9 comune su KVM e, in generale, il modo pi\u00f9 diffuso di virtualizzazione per i sistemi operativi guest. La sua caratteristica \u00e8 che l'interazione con alcuni sottosistemi dell'ipervisore (ad esempio, con lo stack di rete o di storage) o l'assegnazione delle pagine della memoria avviene tramite l'API dell'ipervisore, senza tradurre comandi a basso livello. Lo svantaggio di questo modo di virtualizzazione \u00e8 la necessit\u00e0 di modificare il kernel del sistema operativo guest, affinch\u00e9 possa interagire con l'ipervisore tramite questa API. Ma di solito questo problema si risolve installando driver speciali sul sistema operativo guest. In KVM, questa API si chiama <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 traduzione, il percorso verso il dispositivo fisico si accorcia notevolmente grazie all'invio dei comandi direttamente dalla macchina virtuale al processo dell'ipervisore sull'host. Questo consente di accelerare l'esecuzione di tutte le istruzioni all'interno della macchina virtuale. In KVM, questo \u00e8 gestito dall'API virtio, che funziona solo per alcuni dispositivi, come quelli di rete o di storage. \u00c8 proprio per questo che all'interno delle macchine virtuali vengono installati i driver virtio. <\/p>\n<p>Il rovescio della medaglia di tale accelerazione \u00e8 che non tutti i processi che vengono eseguiti all'interno della macchina virtuale rimangono all'interno di essa. Questo crea alcuni effetti speciali che possono portare all'apparizione di steal. Consiglio di iniziare lo studio approfondito di questo argomento con <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/239238\/\">Un'API per I\/O virtuale: virtio<\/a><\/noindex>.<\/p>\n<h3>2.3. Pianificazione 'giusta'<\/h3>\n<p>\nLa macchina virtuale su un hypervisor \u00e8, di fatto, un processo ordinario che \u00e8 soggetto alle leggi della pianificazione (distribuzione delle risorse tra i processi) nel kernel Linux, quindi lo esamineremo pi\u00f9 a fondo. <\/p>\n<p>In Linux si utilizza il cosiddetto CFS, Completely Fair Scheduler, diventato il gestore di default a partire dal kernel 2.6.23. Per capire questo algoritmo, si possono leggere Linux Kernel Architecture o i sorgenti. L'essenza del CFS risiede 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 'equa' di tutti i processi, affinch\u00e9 un processo non occupi continuamente tutte le CPU e gli altri processi possano essere eseguiti. <\/p>\n<p>A volte, tale paradigma porta a risultati interessanti. I vecchi utenti di Linux ricorderanno sicuramente il blocco di un normale editor di testo sul desktop durante l'avvio di applicazioni che richiedono molte risorse, come il compilatore. Ci\u00f2 avveniva perch\u00e9 i compiti non intensivi delle applicazioni desktop competivano con compiti che consumavano attivamente risorse, come il compilatore. Il CFS considera questo ingiusto, quindi interrompe periodicamente l'editor di testo e consente alla CPU di elaborare i compiti del compilatore. Questo \u00e8 stato corretto attraverso il meccanismo <noindex><a rel=\"nofollow\" href=\"https:\/\/marc.info\/?l=linux-kernel&amp;m=128978361700898\">sched_autogroup<\/a><\/noindex>, ma rimangono molte altre peculiarit\u00e0 nella distribuzione del tempo di CPU tra i compiti. In realt\u00e0, questa non \u00e8 una storia su quanto male sia il CFS, ma un tentativo di richiamare l'attenzione sul fatto che una distribuzione 'equa' del tempo di CPU non \u00e8 un compito triviale.<\/p>\n<p>Un altro punto importante nel pianificatore \u00e8 la preemption. Questo \u00e8 necessario per espellere un processo affamato dalla CPU e dare spazio ad altri processi. Il processo di espulsione si chiama context switching, ovvero il cambio di contesto della CPU. Durante questo processo viene mantenuto tutto il contesto del task: stato dello stack, registri e altro, dopo di che il processo viene messo in attesa e al suo posto ne viene avviato un altro. Questa \u00e8 un'operazione costosa per il sistema operativo e viene utilizzata raramente, ma in sostanza non ha nulla di male. Un frequente cambio di 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>Questa lunga esposizione \u00e8 necessaria per spiegare un fatto: pi\u00f9 risorse cerca di consumare un processo in un pianificatore Linux onesto, pi\u00f9 velocemente sar\u00e0 fermato, affinch\u00e9 anche altri processi possano lavorare. Se questo \u00e8 giusto o meno \u00e8 una questione complessa, che viene risolta in modi diversi a seconda del carico. Fino a poco tempo fa, in Windows, il pianificatore era orientato al trattamento prioritario delle applicazioni desktop, il che poteva causare il blocco dei processi in background. In Sun Solaris c'erano cinque diversi classi di pianificatori. Quando \u00e8 stata avviata la virtualizzazione, ne \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>, perch\u00e9 i precedenti cinque lavoravano in modo inadeguato con la virtualizzazione delle Solaris Zones. Raccomando di iniziare a studiare questo argomento leggendo libri come <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Solaris-Internals-OpenSolaris-Kernel-Architecture\/dp\/0131482092\/\">Solaris Internals: Solaris 10 e Architettura del Kernel di OpenSolaris<\/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 steal?<\/h3>\n<p>\nMonitorare steal all'interno di una macchina virtuale, proprio come qualsiasi altra metrica della CPU, \u00e8 semplice: si pu\u00f2 utilizzare qualsiasi strumento di monitoraggio delle metriche della CPU. L'importante \u00e8 che la virtual machine sia basata su Linux. Per qualche motivo, Windows non fornisce tali informazioni ai suoi utenti. \ud83d\ude41<\/p>\n<p><img decoding=\"async\" alt=\"Ruba: chi ruba tempo di CPU dalle macchine virtuali\" src=\"\/wp-content\/uploads\/2019\/04\/3c7cd04f73fd6a74b86af81382090b69.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Output del comando top: dettagli sul carico della CPU, nell'ultima colonna a destra \u2014 steal<\/i><\/p>\n<p>La difficolt\u00e0 sorge nel tentativo di ottenere queste informazioni dal hypervisor. Si pu\u00f2 provare a prevedere steal sulla macchina host, ad esempio, in base al parametro Load Average (LA) \u2014 valore medio del numero di processi in attesa in coda di esecuzione. Il metodo di calcolo di questo parametro non \u00e8 semplice, ma sostanzialmente, se il LA normalizzato in base al numero di thread della CPU \u00e8 superiore a 1, ci\u00f2 indica che il server con Linux \u00e8 sovraccarico di qualche modo. <\/p>\n<p>Cosa aspettano tutti questi processi? La risposta ovvia \u00e8 il processore. Ma la risposta non \u00e8 del tutto corretta, perch\u00e9 a volte il processore \u00e8 libero, mentre la LA \u00e8 alle stelle. Ricordate, <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/911976\/redhat-nfs-cluster-high-load-average-suddenly\">come si disconnette NFS e come la LA cresce in questo caso.<\/a><\/noindex>Pu\u00f2 succedere lo stesso con il disco e con altri dispositivi di input\/output. Ma in realt\u00e0, i processi possono aspettare la fine di qualsiasi blocco, sia esso fisico, legato a un dispositivo di input\/output, sia logico, ad esempio un mutex. Ci sono anche blocchi a livello di hardware (quella stessa risposta dal disco) o di logica (i cosiddetti primitivi di blocco, che comprendono una quantit\u00e0 di entit\u00e0, mutex adattivi e spin, semafori, variabili di condizione, rw locks, ipc locks... ).<\/p>\n<p>Un'altra caratteristica della LA \u00e8 che viene considerata come una media nel sistema operativo. Ad esempio, 100 processi competono per un file, e allora LA=50. Un valore cos\u00ec alto sembrerebbe indicare che il sistema operativo sta soffrendo. Ma per un codice scritto in modo errato potrebbe essere uno stato normale, in cui a soffrire \u00e8 solo quello, mentre gli altri processi nel sistema operativo non ne risentono. <\/p>\n<p>A causa di questa media (che viene calcolata su un periodo non inferiore a un minuto), definire qualsiasi cosa in base al valore della LA non \u00e8 un compito molto gratificante, e i risultati sono piuttosto incerti nei casi specifici. Se provate a capire meglio, scoprirete che negli articoli di Wikipedia e in altre risorse disponibili vengono descritti solo i casi pi\u00f9 semplici, senza spiegazioni approfondite 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 di seguito con i link. A chi non piacesse leggere in inglese \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/335326\/\">la traduzione del suo articolo popolare sulla LA<\/a><\/noindex>.<\/p>\n<h2>3. Effetti speciali<\/h2>\n<p>\nOra ci fermeremo sui principali casi di steal che abbiamo incontrato. Racconter\u00f2 come derivano da tutto ci\u00f2 che \u00e8 stato detto e come si relazionano con le metriche nel hypervisor.<\/p>\n<p><b>Re-utilizzazione<\/b>. Il pi\u00f9 semplice e comune: il hypervisor \u00e8 sovraccarico. Infatti, ci sono molte macchine virtuali in esecuzione, un grande consumo di processore al loro interno, grande competizione, utilizzo della LA superiore a 1 (normalizzata per i thread del processore). All'interno di tutte le macchine virtuali tutto rallenta. Lo steal passato dal hypervisor cresce anch'esso, \u00e8 necessario riequilibrare il carico o spegnere qualche macchina. Insomma, tutto \u00e8 logico e chiaro.<\/p>\n<p><b>Paravirtualizzazione contro istanze isolate<\/b>. Sul hypervisor c'\u00e8 una sola macchina virtuale, che consuma una piccola parte delle sue risorse, ma genera un carico elevato in termini di input\/output, ad esempio su disco. E da qualche parte in essa appare un piccolo valore di steal, fino al 10% (come hanno mostrato alcuni esperimenti condotti).<\/p>\n<p>Il caso \u00e8 interessante. Lo steal appare qui proprio a causa dei blocchi a livello dei driver paravirtualizzati. All'interno della macchina virtuale viene generata un'interruzione, che viene gestita dal driver e inviata al hypervisor. A causa della gestione dell'interruzione, per la macchina virtuale questo appare come una richiesta inviata, \u00e8 pronta per essere eseguita e aspetta la CPU, ma non le viene dato tempo di processore. La macchina virtuale pensa che quel tempo sia stato rubato. <\/p>\n<p>Questo avviene nel momento in cui si invia un buffer, che va nello spazio del kernel dell'hypervisor, e iniziamo ad aspettarlo. Tuttavia, dal punto di vista della macchina virtuale, dovrebbe tornare immediatamente. Pertanto, secondo l'algoritmo di calcolo dello steal, questo tempo viene considerato rubato. \u00c8 probabile che ci siano altri meccanismi in questa situazione (come l'elaborazione di ulteriori sys calls), ma non dovrebbero differire molto.<\/p>\n<p><b>Scheduler contro macchine virtuali ad alta intensit\u00e0<\/b>. Quando una macchina virtuale soffre di pi\u00f9 steal rispetto alle altre, ci\u00f2 \u00e8 legato proprio allo scheduler. Pi\u00f9 il processo carica la CPU, prima lo scheduler lo esclude, affinch\u00e9 anche gli altri possano lavorare. Se una macchina virtuale consuma poco, non vedr\u00e0 quasi mai lo steal: il suo processo \u00e8 semplicemente seduto ad aspettare, quindi \u00e8 necessario darle pi\u00f9 tempo. Se una macchina virtuale genera un carico massimo su tutti i suoi core, \u00e8 spesso esclusa dalla CPU e si cerca di non darle molto tempo. <\/p>\n<p>\u00c8 ancora peggio quando i processi all'interno della macchina virtuale cercano di ottenere pi\u00f9 CPU, perch\u00e9 non riescono a gestire i dati. In questo caso, il sistema operativo sull'hypervisor, grazie a una corretta ottimizzazione, fornir\u00e0 sempre meno tempo di processore. Questo processo avviene in modo a valanga e lo 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 breve, le macchine virtuali ad alta intensit\u00e0 con molti core soffrono di pi\u00f9.<\/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 determinate macchine virtuali si osserva steal:<\/p>\n<ul>\n<li>La variante descritta sopra con la paravirtualizzazione. La macchina virtuale pu\u00f2 ricevere metriche che indicano il rubare, anche se per l'ipervisore tutto va bene. Dai nostri esperimenti, tale rubare 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 considerato errato. Pi\u00f9 precisamente, in ogni momento specifico viene calcolato correttamente, ma quando si media su un minuto risulta sottostimato. Ad esempio, se una macchina virtuale usa esattamente la met\u00e0 dei suoi processori per trenta secondi, il LA per il minuto sull'ipervisore sar\u00e0 0,15; quattro di queste macchine virtuali che lavorano contemporaneamente daranno 0,6. E il fatto che per trenta secondi ognuna di esse ha avuto un forte rubare del 25% secondo l'indicatore LA, non pu\u00f2 pi\u00f9 essere estratto.\n<\/li>\n<li>Ancora una volta, a causa dello scheduler che ha deciso che qualcuno sta mangiando troppo, e che quella persona deve aspettare. Nel frattempo, cambio contesto, elaboro le interruzioni e mi occupo di altre cose importanti di sistema. Alla fine, alcune macchine virtuali non vedono problemi, mentre altre subiscono una seria degradazione delle prestazioni.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>4. Altre distorsioni<\/h2>\n<p>\nCi sono anche un milione di motivi per le distorsioni nel tempo di CPU onesto sulla macchina virtuale. Ad esempio, le complicazioni nei calcoli sono causate dall'hyper-threading e dal NUMA. Questi complicano ulteriormente la scelta del core per l'esecuzione del processo, poich\u00e9 lo scheduler utilizza coefficienti - pesi - che rendono il conteggio ancora pi\u00f9 difficile durante il cambio di contesto.<\/p>\n<p>Ci possono essere distorsioni dovute a tecnologie come il turbo boost o, al contrario, alla modalit\u00e0 di risparmio energetico, che possono aumentare artificialmente o diminuire la frequenza o anche il quantum di tempo sul server durante il calcolo dell'utilizzo. L'attivazione del turbo boost riduce le prestazioni di un thread di CPU a causa del miglioramento delle prestazioni di un altro. In quel momento, l'informazione sulla frequenza attuale della CPU non viene trasferita alla macchina virtuale, che crede che il suo tempo venga rubato (ad esempio, richiedeva 2 GHz, ma ha ricevuto la met\u00e0). <\/p>\n<p>In generale, ci possono essere molte cause di distorsione. In un sistema specifico potresti scoprire qualcosa di diverso. \u00c8 meglio iniziare dai libri a cui ho fornito i link sopra e dalla raccolta di statistiche dall'ipervisore utilizzando strumenti come perf, sysdig, systemtap, che 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>Una certa quantit\u00e0 di steal pu\u00f2 verificarsi a causa della paravirtualizzazione ed \u00e8 considerata normale. Su Internet si scrive che questa quantit\u00e0 pu\u00f2 arrivare al 5-10%. Dipende dalle applicazioni all'interno della macchina virtuale e dal carico che essa esercita sui suoi dispositivi fisici. \u00c8 importante prestare attenzione a come si comportano le applicazioni all'interno delle macchine virtuali.\n<\/li>\n<li>Il rapporto tra il carico sul hypervisor e lo steal all'interno della macchina virtuale non \u00e8 sempre chiaramente correlato; entrambe le valutazioni dello steal possono essere errate in situazioni specifiche con diversi carichi.\n<\/li>\n<li>Lo scheduler ha una scarsa considerazione per i processi che richiedono molto. Cerca di dare meno a chi chiede di pi\u00f9. Grandi macchine virtuali sono un problema.\n<\/li>\n<li>Un piccolo steal pu\u00f2 essere normale anche senza paravirtualizzazione (considerando il carico all'interno della macchina virtuale, le caratteristiche del carico dei vicini, la distribuzione del carico sui thread e altri fattori).\n<\/li>\n<li>Se desideri determinare lo steal in un sistema specifico, \u00e8 necessario esplorare diverse opzioni, raccogliere metriche, analizzarle attentamente e pensare a come distribuire equamente il carico. Da qualsiasi caso possono derivare deviazioni che devono essere confermate sperimentalmente o verificate 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.1.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.1.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\udd47Furto: chi ruba il tempo di elaborazione delle virtual machine | 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}]}}