{"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\/pt\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","title":{"rendered":"Roubo: quem rouba tempo de CPU de m\u00e1quinas virtuais","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Roubo: quem rouba tempo de CPU de m\u00e1quinas virtuais\" src=\"\/wp-content\/uploads\/2019\/04\/23cac5d3cc3295dc6f1014e9fda36b89.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOl\u00e1! Quero explicar de forma simples a mec\u00e2nica da ocorr\u00eancia de steal dentro das m\u00e1quinas virtuais e alguns artefatos n\u00e3o \u00f3bvios que conseguimos descobrir durante sua investiga\u00e7\u00e3o, na qual tive que me aprofundar como diretor t\u00e9cnico da plataforma em nuvem. <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Solu\u00e7\u00f5es em Nuvem Mail.ru<\/a><\/noindex>. A plataforma opera em KVM.<\/p>\n<p>O tempo de steal da CPU \u00e9 o tempo em que a m\u00e1quina virtual n\u00e3o recebe recursos de CPU para sua execu\u00e7\u00e3o. Esse tempo \u00e9 considerado apenas em sistemas operacionais convidados em ambientes de virtualiza\u00e7\u00e3o. As raz\u00f5es pelas quais esses recursos alocados desaparecem, assim como na vida, s\u00e3o bastante nebulosas. Mas decidimos investigar, at\u00e9 fizemos uma s\u00e9rie de experimentos. N\u00e3o que agora saibamos tudo sobre steal, mas temos algumas informa\u00e7\u00f5es interessantes para compartilhar.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>1. O que \u00e9 steal<\/h2>\n<p>\nEnt\u00e3o, steal \u00e9 uma m\u00e9trica que indica a falta de tempo de CPU para processos dentro da m\u00e1quina virtual. Como descrito <noindex><a rel=\"nofollow\" href=\"https:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/stable\/linux.git\/patch\/?id=c9aaa8957f203bd6df83b002fb40b98390bed078\">no patch do kernel KVM<\/a><\/noindex>, steal \u00e9 o tempo em que o hipervisor executa outros processos no sistema operacional host, enquanto colocou o processo da m\u00e1quina virtual em espera para execu\u00e7\u00e3o. Ou seja, steal \u00e9 considerado como a diferen\u00e7a entre o tempo em que o processo est\u00e1 pronto para ser executado e o tempo em que lhe \u00e9 alocado tempo de CPU.<\/p>\n<p>A m\u00e9trica steal \u00e9 obtida pelo kernel da m\u00e1quina virtual do hipervisor. O hipervisor, no entanto, n\u00e3o especifica quais outros processos ele est\u00e1 executando, apenas \"estou ocupado, n\u00e3o posso dedicar tempo a voc\u00ea agora\". No KVM, o suporte para o c\u00e1lculo de steal foi adicionado em <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/449657\/\">patches<\/a><\/noindex>. H\u00e1 dois pontos-chave aqui: <\/p>\n<ul>\n<li>A m\u00e1quina virtual descobre sobre steal atrav\u00e9s do hipervisor. Ou seja, do ponto de vista das perdas, para os processos na pr\u00f3pria m\u00e1quina virtual, \u00e9 uma medi\u00e7\u00e3o indireta, que pode estar sujeita a v\u00e1rias distor\u00e7\u00f5es.\n<\/li>\n<li>O hipervisor n\u00e3o compartilha com a m\u00e1quina virtual informa\u00e7\u00f5es sobre o que mais est\u00e1 fazendo \u2014 o importante \u00e9 que n\u00e3o est\u00e1 dedicando tempo a ela. Por causa disso, a pr\u00f3pria m\u00e1quina virtual n\u00e3o pode identificar distor\u00e7\u00f5es na m\u00e9trica steal que poderiam ser avaliadas segundo o tipo de processos concorrentes.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. O que afeta o steal<\/h2>\n<p><\/p>\n<h3>2.1. C\u00e1lculo do steal<\/h3>\n<p>\nEssencialmente, steal \u00e9 calculado de forma semelhante ao tempo normal de utiliza\u00e7\u00e3o da CPU. H\u00e1 poucas informa\u00e7\u00f5es sobre como a utiliza\u00e7\u00e3o \u00e9 calculada. Provavelmente, porque a maioria considera essa quest\u00e3o \u00f3bvia. Mas tamb\u00e9m existem armadilhas aqui. Para se familiarizar com esse processo, pode-se ler <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-05-09\/cpu-utilization-is-wrong.html\">o artigo de Brendann Gregg<\/a><\/noindex>: voc\u00ea aprender\u00e1 sobre uma s\u00e9rie de nuances ao calcular a utiliza\u00e7\u00e3o e sobre situa\u00e7\u00f5es em que esse c\u00e1lculo pode estar incorreto por raz\u00f5es seguintes:<\/p>\n<ul>\n<li>Superaquecimento do processador, durante o qual ciclos s\u00e3o perdidos.\n<\/li>\n<li>Ativa\u00e7\u00e3o\/desativa\u00e7\u00e3o do turbo boost, resultando em uma altera\u00e7\u00e3o na frequ\u00eancia do processador.\n<\/li>\n<li>Mudan\u00e7a na dura\u00e7\u00e3o do quanta de tempo, que ocorre ao usar tecnologias de economia de energia do processador, como o SpeedStep.\n<\/li>\n<li>O problema do c\u00e1lculo m\u00e9dio: uma avalia\u00e7\u00e3o de utiliza\u00e7\u00e3o de 80% ao longo de um minuto pode ocultar um pico de curto prazo de 100%.\n<\/li>\n<li>O bloqueio c\u00edclico (spin lock) resulta em uma utiliza\u00e7\u00e3o do processador, mas o processo do usu\u00e1rio n\u00e3o v\u00ea progresso em sua execu\u00e7\u00e3o. Como resultado, a utiliza\u00e7\u00e3o calculada do processador pelo processo ser\u00e1 de cem por cento, embora o tempo do processador n\u00e3o esteja sendo consumido fisicamente.\n<\/li>\n<\/ul>\n<p>\nN\u00e3o encontrei artigos descrevendo esse c\u00e1lculo para steal (se voc\u00ea souber \u2014 compartilhe nos coment\u00e1rios). Mas, conforme as fontes, o mecanismo de c\u00e1lculo \u00e9 o mesmo que para utiliza\u00e7\u00e3o. Apenas no n\u00facleo \u00e9 adicionado mais um contador, diretamente para o processo KVM (do processo da m\u00e1quina virtual), que conta a dura\u00e7\u00e3o da perman\u00eancia do processo KVM em estado de espera por tempo de CPU. O contador obt\u00e9m informa\u00e7\u00f5es sobre o processador de suas especifica\u00e7\u00f5es e verifica se todos os seus ciclos foram utilizados pelo processo da m\u00e1quina virtual. Se sim, consideramos que o processador estava apenas com o processo da m\u00e1quina virtual. Caso contr\u00e1rio, informamos que o processador estava ocupado com algo mais, ocorreu steal. <\/p>\n<p>O processo de c\u00e1lculo do steal enfrenta os mesmos problemas que o c\u00e1lculo normal de utiliza\u00e7\u00e3o. N\u00e3o se pode dizer que esses problemas apare\u00e7am frequentemente, mas t\u00eam um aspecto desanimador.<\/p>\n<h3>2.2. Tipos de virtualiza\u00e7\u00e3o no KVM<\/h3>\n<p>\nDe maneira geral, existem tr\u00eas tipos de virtualiza\u00e7\u00e3o, e todos s\u00e3o suportados pelo KVM. O tipo de virtualiza\u00e7\u00e3o pode influenciar o mecanismo de ocorr\u00eancia de steal.<\/p>\n<p><b>Transmiss\u00e3o<\/b>. Nesse caso, a opera\u00e7\u00e3o do sistema operacional da m\u00e1quina virtual com dispositivos f\u00edsicos do hipervisor ocorre aproximadamente assim:<\/p>\n<ol>\n<li>O sistema operacional convidado envia um comando para seu dispositivo convidado.\n<\/li>\n<li>O driver do dispositivo convidado recebe o comando, forma uma solicita\u00e7\u00e3o para a BIOS do dispositivo e a envia ao hipervisor.\n<\/li>\n<li>O processo do hipervisor traduz o comando em um comando para o dispositivo f\u00edsico, tornando-o, entre outras coisas, mais seguro.\n<\/li>\n<li>O driver do dispositivo f\u00edsico aceita o comando modificado e o envia ao pr\u00f3prio dispositivo f\u00edsico.\n<\/li>\n<li>Os resultados da execu\u00e7\u00e3o dos comandos retornam pelo mesmo caminho. \n<\/li>\n<\/ol>\n<p>\nA vantagem da tradu\u00e7\u00e3o \u00e9 que ela permite emular qualquer dispositivo e n\u00e3o requer prepara\u00e7\u00e3o especial do n\u00facleo do sistema operacional. Mas isso vem \u00e0 custa, principalmente, do desempenho. <\/p>\n<p><b>Virtualiza\u00e7\u00e3o de hardware<\/b>. Nesse caso, o dispositivo em n\u00edvel de hardware compreende os comandos do sistema operacional. Esta \u00e9 a maneira mais r\u00e1pida e eficiente. Mas, infelizmente, n\u00e3o \u00e9 suportada por todos os dispositivos f\u00edsicos, hipervisores e sistemas operacionais convidados. Atualmente, os principais dispositivos que suportam virtualiza\u00e7\u00e3o de hardware s\u00e3o os processadores.<\/p>\n<p><b>Paravirtualiza\u00e7\u00e3o<\/b>. A op\u00e7\u00e3o mais comum de virtualiza\u00e7\u00e3o de dispositivos no KVM e, de forma geral, o modo de virtualiza\u00e7\u00e3o mais amplamente utilizado para sistemas operacionais convidados. A caracter\u00edstica \u00e9 que a intera\u00e7\u00e3o com alguns subsistemas do hipervisor (por exemplo, a pilha de rede ou de disco) ou a aloca\u00e7\u00e3o de p\u00e1ginas de mem\u00f3ria \u00e9 realizada utilizando a API do hipervisor, sem a tradu\u00e7\u00e3o de comandos de baixo n\u00edvel. A desvantagem desse m\u00e9todo de virtualiza\u00e7\u00e3o \u00e9 a necessidade de modificar o n\u00facleo do sistema operacional convidado para que ele possa interagir com o hipervisor atrav\u00e9s dessa API. No entanto, isso geralmente \u00e9 resolvido por meio da instala\u00e7\u00e3o de drivers especiais no sistema operacional convidado. No KVM, essa API \u00e9 chamada <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/developerworks\/library\/l-virtio\/index.html\">virtio API<\/a><\/noindex>.<\/p>\n<p>Na paravirtualiza\u00e7\u00e3o, em compara\u00e7\u00e3o com a tradu\u00e7\u00e3o, o caminho at\u00e9 o dispositivo f\u00edsico \u00e9 significativamente encurtado ao enviar comandos diretamente da m\u00e1quina virtual para o processo do hipervisor no host. Isso permite acelerar a execu\u00e7\u00e3o de todas as instru\u00e7\u00f5es dentro da m\u00e1quina virtual. No KVM, isso \u00e9 gerido pela virtio API, que funciona apenas para dispositivos espec\u00edficos, como adaptadores de rede ou de disco. \u00c9 por isso que drivers virtio s\u00e3o instalados dentro das m\u00e1quinas virtuais. <\/p>\n<p>O reverso desse aumento de desempenho \u00e9 que nem todos os processos que ocorrem dentro da m\u00e1quina virtual permanecem dentro dela. Isso cria alguns efeitos especiais que podem levar \u00e0 apari\u00e7\u00e3o em steal. Recomendo come\u00e7ar um estudo mais profundo sobre este assunto com <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/239238\/\">Uma API para I\/O virtual: virtio<\/a><\/noindex>.<\/p>\n<h3>2.3. Agendamento 'Justo'<\/h3>\n<p>\nUma m\u00e1quina virtual em um hipervisor \u00e9, na verdade, um processo comum que segue as leis de escalonamento (distribui\u00e7\u00e3o de recursos entre processos) no n\u00facleo Linux, ent\u00e3o vamos examin\u00e1-la mais detalhadamente. <\/p>\n<p>No Linux, utiliza-se o chamado CFS, Completely Fair Scheduler, que desde o n\u00facleo 2.6.23 tornou-se o escalonador padr\u00e3o. Para entender melhor este algoritmo, pode-se ler o Linux Kernel Architecture ou os c\u00f3digos-fonte. A ess\u00eancia do CFS reside na distribui\u00e7\u00e3o do tempo de CPU entre os processos, dependendo da dura\u00e7\u00e3o de sua execu\u00e7\u00e3o. Quanto mais tempo de CPU um processo exige, menos tempo ele recebe. Isso garante a execu\u00e7\u00e3o 'justa' de todos os processos \u2014 para que um \u00fanico processo n\u00e3o monopolize toda a CPU continuamente, permitindo que os outros processos tamb\u00e9m sejam executados. <\/p>\n<p>\u00c0s vezes, essa paradigma leva a artefatos interessantes. Usu\u00e1rios antigos do Linux certamente lembram da paralisa\u00e7\u00e3o de editores de texto comuns na \u00e1rea de trabalho durante a execu\u00e7\u00e3o de aplicativos que consomem muitos recursos, como compiladores. Isso acontecia porque tarefas menos exigentes de aplicativos de desktop competiam com tarefas que consomem recursos ativamente, como o compilador. O CFS considera isso injusto, por isso, periodicamente, ele interrompe o editor de texto e permite que a CPU processe as tarefas do compilador. Isso foi corrigido com o mecanismo <noindex><a rel=\"nofollow\" href=\"https:\/\/marc.info\/?l=linux-kernel&amp;m=128978361700898\">sched_autogroup<\/a><\/noindex>, mas muitas outras peculiaridades da distribui\u00e7\u00e3o do tempo de CPU entre tarefas ainda permanecem. Na verdade, esta \u00e9 uma narrativa n\u00e3o sobre como tudo \u00e9 ruim no CFS, mas uma tentativa de chamar aten\u00e7\u00e3o para o fato de que a distribui\u00e7\u00e3o 'justa' do tempo de CPU n\u00e3o \u00e9 uma tarefa trivial.<\/p>\n<p>Outro ponto importante no escalonador \u00e9 a preemption. Isso \u00e9 necess\u00e1rio para remover um processo que est\u00e1 consumindo muitos recursos do processador e permitir que outros possam ser executados. O processo de remo\u00e7\u00e3o \u00e9 chamado de context switching, ou troca de contexto do processador. Durante isso, todo o contexto da tarefa \u00e9 preservado: o estado da pilha, os registradores e outros elementos, ap\u00f3s o que o processo \u00e9 enviado para esperar, e outro ocupa seu lugar. Essa \u00e9 uma opera\u00e7\u00e3o cara para o sistema operacional, utilizada raramente, mas essencialmente n\u00e3o h\u00e1 nada de ruim nisso. Uma troca de contexto frequente pode indicar um problema no sistema operacional, mas, normalmente, ela ocorre continuamente e n\u00e3o indica especificamente nada.<\/p>\n<p>Essa longa explica\u00e7\u00e3o \u00e9 necess\u00e1ria para clarificar um fato: quanto mais recursos do processador um processo tenta consumir em um escalonador honesto do Linux, mais rapidamente ele ser\u00e1 interrompido para que outros processos tamb\u00e9m possam ser executados. Se isso \u00e9 certo ou n\u00e3o \u00e9 uma quest\u00e3o complexa, que \u00e9 resolvida de formas diferentes sob diferentes cargas. No Windows, at\u00e9 recentemente, o escalonador era orientado para o processamento priorit\u00e1rio de aplicativos de desktop, o que poderia causar travamentos em processos em segundo plano. No Sun Solaris, havia cinco classes diferentes de escalonadores. Quando a virtualiza\u00e7\u00e3o foi introduzida, uma sexta classe foi adicionada, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opennet.ru\/man.shtml?topic=FSS&amp;category=7&amp;russian=4\">escalonador de compartilhamento justo<\/a><\/noindex>, porque as cinco anteriores lidavam com a virtualiza\u00e7\u00e3o das Solaris Zones de forma inadequada. Recomendo come\u00e7ar um estudo detalhado desse assunto com livros como <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Solaris-Internals-OpenSolaris-Kernel-Architecture\/dp\/0131482092\/\">Solaris Internals: Solaris 10 e Arquitetura do Kernel OpenSolaris<\/a><\/noindex> ou <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. Como monitorar o steal?<\/h3>\n<p>\nMonitorar o steal dentro de uma m\u00e1quina virtual, assim como qualquer outra m\u00e9trica de processador, \u00e9 simples: pode-se usar qualquer ferramenta de coleta de m\u00e9tricas de CPU. A \u00fanica condi\u00e7\u00e3o \u00e9 que a virtualiza\u00e7\u00e3o esteja no Linux. O Windows, por algum motivo, n\u00e3o fornece essa informa\u00e7\u00e3o aos seus usu\u00e1rios. \ud83d\ude41<\/p>\n<p><img decoding=\"async\" alt=\"Roubo: quem rouba tempo de CPU de m\u00e1quinas virtuais\" src=\"\/wp-content\/uploads\/2019\/04\/3c7cd04f73fd6a74b86af81382090b69.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sa\u00edda do comando top: detalhamento da carga na CPU, na coluna mais \u00e0 direita \u2014 steal<\/i><\/p>\n<p>A dificuldade surge ao tentar obter essa informa\u00e7\u00e3o a partir do hipervisor. \u00c9 poss\u00edvel tentar prever o steal na m\u00e1quina host, por exemplo, pelo par\u00e2metro Load Average (LA) \u2014 valor m\u00e9dio do n\u00famero de processos esperando na fila para serem executados. A metodologia para calcular esse par\u00e2metro n\u00e3o \u00e9 simples, mas, de modo geral, se o LA, normalizado pelo n\u00famero de threads do processador, for maior que 1, isso indica que o servidor Linux est\u00e1 sobrecarregado. <\/p>\n<p>O que todos esses processos est\u00e3o esperando? A resposta \u00f3bvia \u00e9 o processador. Mas a resposta n\u00e3o est\u00e1 completamente correta, porque \u00e0s vezes o processador est\u00e1 livre e a LA est\u00e1 elevada. Lembre-se, <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/911976\/redhat-nfs-cluster-high-load-average-suddenly\">de como o NFS falha e como a LA cresce nesse caso.<\/a><\/noindex>Da mesma forma, isso pode ocorrer com o disco e outros dispositivos de entrada\/sa\u00edda. Na verdade, os processos podem aguardar o t\u00e9rmino de qualquer bloqueio, seja f\u00edsico, relacionado ao dispositivo de entrada\/sa\u00edda, ou l\u00f3gico, como um mutex. Tamb\u00e9m est\u00e3o inclu\u00eddos bloqueios em n\u00edvel de hardware (como a resposta do disco) ou de l\u00f3gica (os chamados primitivos de bloqueio, que englobam v\u00e1rias entidades, como mutex adaptativo e spin, sem\u00e1foros, vari\u00e1veis de condi\u00e7\u00e3o, bloqueios rw, bloqueios ipc\u2026)<\/p>\n<p>Outra caracter\u00edstica da LA \u00e9 que ela \u00e9 considerada como uma m\u00e9dia para o sistema operacional. Por exemplo, 100 processos competindo por um arquivo, ent\u00e3o LA=50. Um valor t\u00e3o alto poderia, \u00e0 primeira vista, indicar que o sistema operacional est\u00e1 com problemas. Mas, para um c\u00f3digo mal escrito, isso pode ser uma condi\u00e7\u00e3o normal, onde apenas ele est\u00e1 com problemas, enquanto os outros processos no sistema operacional n\u00e3o sofrem. <\/p>\n<p>Devido a essa m\u00e9dia (e n\u00e3o menos do que um minuto), definir qualquer coisa pela m\u00e9trica de LA n\u00e3o \u00e9 uma tarefa f\u00e1cil, com resultados bem indefinidos em casos espec\u00edficos. Se voc\u00ea tentar se aprofundar, descobrir\u00e1 que nos artigos da Wikipedia e em outros recursos dispon\u00edveis est\u00e3o descritos apenas os casos mais simples, sem uma explica\u00e7\u00e3o profunda do processo. Para todos os interessados, envio, mais uma vez, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-08-08\/linux-load-averages.html\">para c\u00e1, para Brendann Gregg<\/a><\/noindex> \u00a0\u2014 e siga os links. Para quem n\u00e3o quer ler em ingl\u00eas \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/335326\/\">a tradu\u00e7\u00e3o de seu artigo popular sobre LA<\/a><\/noindex>.<\/p>\n<h2>3. Efeitos Especiais<\/h2>\n<p>\nAgora, vamos nos concentrar nos principais casos de aparecimento de steal, com os quais j\u00e1 nos deparamos. Vou contar como eles surgem a partir de tudo que foi dito e como se relacionam com os indicadores no hipervisor.<\/p>\n<p><b>Reutiliza\u00e7\u00e3o<\/b>. O mais simples e comum: o hipervisor est\u00e1 sobrecarregado. Realmente, muitas m\u00e1quinas virtuais rodando, alto consumo de CPU dentro delas, grande competi\u00e7\u00e3o, utiliza\u00e7\u00e3o por LA superior a 1 (normalizado por threads de processador). Dentro de todas as m\u00e1quinas virtuais, tudo fica lento. O steal, passado pelo hipervisor, tamb\u00e9m aumenta; \u00e9 necess\u00e1rio redistribuir a carga ou desligar algu\u00e9m. No geral, tudo faz sentido e \u00e9 claro.<\/p>\n<p><b>Paravirtualiza\u00e7\u00e3o contra inst\u00e2ncias solit\u00e1rias<\/b>. No hipervisor h\u00e1 uma \u00fanica m\u00e1quina virtual, que consome uma pequena parte dele, mas gera uma grande carga de entrada\/sa\u00edda, por exemplo, no disco. E de algum lugar aparece um pequeno steal nela, de at\u00e9 10% (como mostram alguns experimentos realizados).<\/p>\n<p>Um caso interessante. O steal aqui aparece exatamente devido a bloqueios no n\u00edvel dos drivers paravirtualizados. Dentro da m\u00e1quina virtual, uma interrup\u00e7\u00e3o \u00e9 criada, \u00e9 processada pelo driver e vai para o hipervisor. Devido ao processamento da interrup\u00e7\u00e3o no hipervisor, para a m\u00e1quina virtual isso parece um pedido enviado, ela est\u00e1 pronta para execu\u00e7\u00e3o e espera pelo processador, mas n\u00e3o recebe tempo de processador. A m\u00e1quina virtual pensa que esse tempo foi roubado. <\/p>\n<p>Isso acontece no momento em que o buffer \u00e9 enviado, ele vai para o kernel space do hipervisor, e come\u00e7amos a aguard\u00e1-lo. Embora, do ponto de vista da m\u00e1quina virtual, ele deva retornar imediatamente. Consequentemente, de acordo com o algoritmo de c\u00e1lculo do steal, esse tempo \u00e9 considerado roubado. Provavelmente, nessa situa\u00e7\u00e3o, outros mecanismos podem estar presentes (como o processamento de outras chamadas do sistema), mas eles n\u00e3o devem ser muito diferentes.<\/p>\n<p><b>Escalonador contra m\u00e1quinas virtuais de alto desempenho<\/b>. Quando uma m\u00e1quina virtual sofre de steal mais do que as outras, isso est\u00e1 realmente relacionado ao escalonador. Quanto mais forte o processo carga o processador, mais r\u00e1pido o escalonador o expulsar\u00e1, para que outros tamb\u00e9m possam trabalhar. Se a m\u00e1quina virtual consome pouco, ela quase n\u00e3o perceber\u00e1 steal: seu processo honestamente ficou esperando, precisa de mais tempo. Se a m\u00e1quina virtual gera carga m\u00e1xima em todos os seus n\u00facleos, ela \u00e9 expulsa com mais frequ\u00eancia do processador e tentam n\u00e3o lhe dar muito tempo. <\/p>\n<p>\u00c9 ainda pior quando processos dentro da m\u00e1quina virtual tentam obter mais do processador, porque n\u00e3o conseguem lidar com o processamento de dados. Nesse caso, o sistema operacional no hipervisor, atrav\u00e9s de otimiza\u00e7\u00e3o justa, dar\u00e1 cada vez menos tempo de processador. Esse processo ocorre de forma avalanche, e o steal dispara para as alturas, embora as outras m\u00e1quinas virtuais possam quase n\u00e3o notar. E quanto mais n\u00facleos, pior para a m\u00e1quina que est\u00e1 passando por isso. Em resumo, m\u00e1quinas virtuais de alto desempenho com muitos n\u00facleos s\u00e3o as que mais sofrem.<\/p>\n<p><b>LA baixo, mas h\u00e1 steal<\/b>. Se o LA est\u00e1 em torno de 0,7 (ou seja, o hipervisor parece subcarregado), mas dentro de m\u00e1quinas virtuais espec\u00edficas h\u00e1 steal:<\/p>\n<ul>\n<li>A variante j\u00e1 descrita acima com paravirtualiza\u00e7\u00e3o. A m\u00e1quina virtual pode receber m\u00e9tricas indicando steal, embora o hipervisor esteja bem. De acordo com nossos experimentos, tal steal n\u00e3o ultrapassa 10% e n\u00e3o deve ter um impacto significativo no desempenho dos aplicativos dentro da m\u00e1quina virtual.\n<\/li>\n<li>O par\u00e2metro LA \u00e9 calculado incorretamente. Na verdade, em cada momento espec\u00edfico, ele \u00e9 calculado corretamente, mas ao ser mediado por um minuto, o resultado fica subestimado. Por exemplo, se uma m\u00e1quina virtual consome todos os seus processadores por exatamente meia minuto, o LA do hipervisor ser\u00e1 0,15; quatro m\u00e1quinas virtuais desse tipo funcionando ao mesmo tempo dar\u00e3o 0,6. Entretanto, o que aconteceu por meia minuto, onde cada uma delas apresentou um steal de at\u00e9 25% em LA, n\u00e3o pode ser recuperado.\n<\/li>\n<li>Novamente, devido ao escalonador, que decidiu que algu\u00e9m est\u00e1 consumindo demais e que essa pessoa deve esperar. Enquanto isso, eu troco o contexto, lido com as interrup\u00e7\u00f5es e cuido de outras quest\u00f5es importantes do sistema. Como resultado, algumas m\u00e1quinas virtuais n\u00e3o veem nenhum problema, enquanto outras experimentam uma degrada\u00e7\u00e3o significativa no desempenho.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>4. Outras distor\u00e7\u00f5es<\/h2>\n<p>\nH\u00e1 ainda milh\u00f5es de raz\u00f5es para distor\u00e7\u00f5es na aloca\u00e7\u00e3o justa do tempo de CPU em uma m\u00e1quina virtual. Por exemplo, as complexidades no c\u00e1lculo s\u00e3o trazidas pelo hyper-threading e NUMA. Eles complicam definitivamente a escolha do n\u00facleo para a execu\u00e7\u00e3o do processo, j\u00e1 que o escalonador utiliza coeficientes \u2014 pesos que tornam o c\u00e1lculo ainda mais complexo na troca de contexto.<\/p>\n<p>Pode haver distor\u00e7\u00f5es devido a tecnologias como turbo boost ou, ao contr\u00e1rio, modo de economia de energia, que ao calcular a utiliza\u00e7\u00e3o podem aumentar ou diminuir artificialmente a frequ\u00eancia ou at\u00e9 mesmo o tempo de qu\u00e2ntum no servidor. A ativa\u00e7\u00e3o do turbo boost reduz o desempenho de um thread da CPU devido ao aumento de desempenho de outro. Nesse momento, a informa\u00e7\u00e3o sobre a frequ\u00eancia atual do processador n\u00e3o \u00e9 transmitida para a m\u00e1quina virtual, que acredita que seu tempo est\u00e1 sendo roubado (por exemplo, ela solicitava 2 GHz, mas recebeu metade disso). <\/p>\n<p>Em geral, pode haver muitas raz\u00f5es para distor\u00e7\u00f5es. Em um sistema espec\u00edfico, voc\u00ea pode descobrir algo mais. \u00c9 melhor come\u00e7ar com os livros que citei acima e coletar estat\u00edsticas do hipervisor usando utilit\u00e1rios como perf, sysdig, systemtap, que s\u00e3o <noindex><a rel=\"nofollow\" href=\"https:\/\/jvns.ca\/blog\/2017\/07\/05\/linux-tracing-systems\/\">dezena<\/a><\/noindex>.<\/p>\n<h2>5. Conclus\u00f5es<\/h2>\n<p><\/p>\n<ol>\n<li>Uma certa quantidade de steal pode ocorrer devido \u00e0 paravirtualiza\u00e7\u00e3o, e isso pode ser considerado normal. Na internet, escreve-se que esse valor pode variar de 5 a 10%. Depende dos aplicativos dentro da m\u00e1quina virtual e da carga que ela imp\u00f5e em seus dispositivos f\u00edsicos. Aqui \u00e9 importante observar como os aplicativos se comportam dentro das m\u00e1quinas virtuais.\n<\/li>\n<li>A rela\u00e7\u00e3o entre a carga no hipervisor e o steal dentro da m\u00e1quina virtual nem sempre est\u00e1 claramente interligada; ambas as avalia\u00e7\u00f5es de steal podem ser imprecisas em situa\u00e7\u00f5es espec\u00edficas com diferentes cargas.\n<\/li>\n<li>O escalonador tende a ser hostil com processos que fazem muitos pedidos. Ele tenta dar menos tempo a quem pede mais. Grandes m\u00e1quinas virtuais s\u00e3o uma desvantagem.\n<\/li>\n<li>Um pequeno steal pode ser normal mesmo sem paravirtualiza\u00e7\u00e3o (considerando a carga dentro da m\u00e1quina virtual, caracter\u00edsticas das cargas vizinhas, distribui\u00e7\u00e3o da carga por threads e outros fatores).\n<\/li>\n<li>Se voc\u00ea deseja descobrir o steal em um sistema espec\u00edfico, \u00e9 necess\u00e1rio investigar v\u00e1rias op\u00e7\u00f5es, coletar m\u00e9tricas, analis\u00e1-las cuidadosamente e pensar em como distribuir a carga de forma equitativa. A partir de quaisquer casos, podem ocorrer desvios que precisam ser confirmados experimentalmente ou analisados no depurador do n\u00facleo.\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.3 - 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\/pt\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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: quem rouba o tempo de CPU das m\u00e1quinas virtuais | ProHoster","description":"Ol\u00e1!","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/32331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=32331"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/32331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/24147"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=32331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=32331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=32331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}