{"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\/es\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","title":{"rendered":"Steal: qui\u00e9n roba tiempo de CPU en las m\u00e1quinas virtuales","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Steal: qui\u00e9n roba tiempo de CPU en las m\u00e1quinas virtuales\" src=\"\/wp-content\/uploads\/2019\/04\/23cac5d3cc3295dc6f1014e9fda36b89.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00a1Hola! Quiero hablar de manera sencilla sobre la mec\u00e1nica de la aparici\u00f3n del steal dentro de las m\u00e1quinas virtuales y sobre algunos artefactos poco evidentes que hemos logrado descubrir en nuestra investigaci\u00f3n, en la que me vi involucrado como director t\u00e9cnico de la plataforma en la nube. <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Soluciones en la Nube de Mail.ru<\/a><\/noindex>. La plataforma funciona en KVM.<\/p>\n<p>El tiempo de CPU steal es el tiempo durante el cual la m\u00e1quina virtual no recibe recursos de CPU para su ejecuci\u00f3n. Este tiempo se considera solo en sistemas operativos invitados en entornos de virtualizaci\u00f3n. Las razones por las cuales estos recursos asignados desaparecen son, al igual que en la vida, bastante nebulosas. Pero decidimos investigar, incluso realizamos toda una serie de experimentos. No es que ahora sepamos todo sobre el steal, pero vamos a contar algunas cosas interesantes.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>1. \u00bfQu\u00e9 es el steal?<\/h2>\n<p>\nEntonces, el steal es una m\u00e9trica que indica la falta de tiempo de CPU para los procesos dentro de la m\u00e1quina virtual. Como se describe <noindex><a rel=\"nofollow\" href=\"https:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/stable\/linux.git\/patch\/?id=c9aaa8957f203bd6df83b002fb40b98390bed078\">en el parche del n\u00facleo de KVM<\/a><\/noindex>, el steal es el tiempo durante el cual el hipervisor ejecuta otros procesos en el sistema operativo host, aunque ha puesto el proceso de la m\u00e1quina virtual en cola para su ejecuci\u00f3n. Es decir, el steal se calcula como la diferencia entre el tiempo en que el proceso est\u00e1 listo para ejecutarse y el tiempo en que se le asigna tiempo de CPU.<\/p>\n<p>La m\u00e9trica de steal la obtiene el n\u00facleo de la m\u00e1quina virtual del hipervisor. Sin embargo, el hipervisor no especifica qu\u00e9 otros procesos est\u00e1 ejecutando, simplemente dice: \u2018mientras estoy ocupado, no puedo dedicarte tiempo\u2019. En KVM, el soporte para el conteo del steal se a\u00f1adi\u00f3 en <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/449657\/\">los parches.<\/a><\/noindex>Aqu\u00ed hay dos aspectos clave: <\/p>\n<ul>\n<li>La m\u00e1quina virtual se entera del steal por parte del hipervisor. Es decir, desde el punto de vista de las p\u00e9rdidas, para los procesos en la propia m\u00e1quina virtual es una medida indirecta, que puede estar sujeta a diversas distorsiones.\n<\/li>\n<li>El hipervisor no comparte con la m\u00e1quina virtual informaci\u00f3n sobre en qu\u00e9 m\u00e1s est\u00e1 ocupado, lo importante es que no le dedica tiempo. Debido a esto, la propia m\u00e1quina virtual no puede identificar distorsiones en la m\u00e9trica de steal que podr\u00edan evaluarse por la naturaleza de los procesos en competencia.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. \u00bfQu\u00e9 influye en el steal?<\/h2>\n<p><\/p>\n<h3>2.1. C\u00e1lculo del steal<\/h3>\n<p>\nEn esencia, el steal se calcula de manera similar al tiempo de utilizaci\u00f3n normal de la CPU. Hay poca informaci\u00f3n sobre c\u00f3mo se calcula la utilizaci\u00f3n, probablemente porque la mayor\u00eda considera que esta cuesti\u00f3n es obvia. Pero tambi\u00e9n hay trampas en este aspecto. Para familiarizarse con este proceso, se puede leer. <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-05-09\/cpu-utilization-is-wrong.html\">el art\u00edculo de Brendann Gregg<\/a><\/noindex>: aprender\u00e1s sobre una serie de matices al calcular la utilizaci\u00f3n y sobre las situaciones en las que este c\u00e1lculo puede ser err\u00f3neo por las siguientes razones:<\/p>\n<ul>\n<li>Sobrecalentamiento del procesador, donde se omiten ciclos.\n<\/li>\n<li>Activaci\u00f3n\/desactivaci\u00f3n del turbo boost, lo que altera la frecuencia del reloj del procesador.\n<\/li>\n<li>Cambio en la duraci\u00f3n del quantum de tiempo, que ocurre al usar tecnolog\u00edas de ahorro de energ\u00eda del procesador, como SpeedStep.\n<\/li>\n<li>Problema del c\u00e1lculo medio: estimar la utilizaci\u00f3n durante un minuto al 80 % puede ocultar un pico temporal del 100 %.\n<\/li>\n<li>El bloqueo c\u00edclico (spin lock) provoca que el procesador est\u00e9 utilizado, pero el proceso del usuario no avanza en su ejecuci\u00f3n. Como resultado, la utilizaci\u00f3n calculada del procesador por el proceso ser\u00e1 del cien por ciento, aunque f\u00edsicamente el tiempo del procesador no se est\u00e9 consumiendo.\n<\/li>\n<\/ul>\n<p>\nNo encontr\u00e9 art\u00edculos que describieran un c\u00e1lculo similar para el steal (si lo conocen \u2014 comp\u00e1rtanlo en los comentarios). Sin embargo, seg\u00fan el c\u00f3digo fuente, el mecanismo de c\u00e1lculo es el mismo que para la utilizaci\u00f3n. Simplemente, en el n\u00facleo se a\u00f1ade otro contador, directamente para el proceso KVM (proceso de la m\u00e1quina virtual), que cuenta la duraci\u00f3n de la espera del proceso KVM por tiempo de procesador. El contador obtiene informaci\u00f3n sobre el procesador de sus especificaciones y verifica si todos sus ciclos est\u00e1n siendo utilizados por el proceso de la m\u00e1quina virtual. Si todos, consideramos que el procesador solo estaba dedicado al proceso de la m\u00e1quina virtual. De lo contrario, informamos que el procesador estaba ocupado con algo m\u00e1s, apareci\u00f3 el steal. <\/p>\n<p>El proceso de c\u00e1lculo del steal est\u00e1 sujeto a los mismos problemas que el c\u00e1lculo normal de utilizaci\u00f3n. No se puede decir que estos problemas ocurran con frecuencia, pero son desalentadores.<\/p>\n<h3>2.2. Tipos de virtualizaci\u00f3n en KVM<\/h3>\n<p>\nEn general, hay tres tipos de virtualizaci\u00f3n, y todos son compatibles con KVM. El tipo de virtualizaci\u00f3n puede afectar el mecanismo de aparici\u00f3n del steal.<\/p>\n<p><b>Traducci\u00f3n<\/b>. En este caso, el funcionamiento del sistema operativo de la m\u00e1quina virtual con los dispositivos f\u00edsicos del hipervisor se realiza de la siguiente manera:<\/p>\n<ol>\n<li>El sistema operativo invitado env\u00eda un comando a su dispositivo invitado.\n<\/li>\n<li>El controlador del dispositivo invitado recibe el comando, genera una solicitud para la BIOS del dispositivo y la env\u00eda al hipervisor.\n<\/li>\n<li>El proceso del hipervisor traduce el comando en un comando para el dispositivo f\u00edsico, haci\u00e9ndolo, entre otras cosas, m\u00e1s seguro.\n<\/li>\n<li>El controlador del dispositivo f\u00edsico recibe el comando modificado y lo env\u00eda al propio dispositivo f\u00edsico.\n<\/li>\n<li>Los resultados de la ejecuci\u00f3n de los comandos regresan por el mismo camino. \n<\/li>\n<\/ol>\n<p>\nLa ventaja de la traducci\u00f3n es que permite emular cualquier dispositivo y no requiere una preparaci\u00f3n especial del n\u00facleo del sistema operativo. Pero esto tiene un costo, principalmente en t\u00e9rminos de velocidad. <\/p>\n<p><b>Virtualizaci\u00f3n hardware<\/b>. En este caso, el dispositivo a nivel de hardware entiende los comandos del sistema operativo. Este es el m\u00e9todo m\u00e1s r\u00e1pido y eficaz. Sin embargo, desafortunadamente, no es compatible con todos los dispositivos f\u00edsicos, hipervisores y sistemas operativos invitados. En la actualidad, los principales dispositivos que soportan la virtualizaci\u00f3n de hardware son los procesadores.<\/p>\n<p><b>Paravirtualizaci\u00f3n<\/b>. Es la variante m\u00e1s utilizada de virtualizaci\u00f3n de dispositivos en KVM y, en general, el modo m\u00e1s com\u00fan de virtualizaci\u00f3n para sistemas operativos invitados. Su caracter\u00edstica es que la interacci\u00f3n con algunos subsistemas del hipervisor (por ejemplo, con el stack de red o de disco) o la asignaci\u00f3n de p\u00e1ginas de memoria se realiza utilizando la API del hipervisor, sin la traducci\u00f3n de comandos de bajo nivel. La desventaja de este m\u00e9todo de virtualizaci\u00f3n es la necesidad de modificar el n\u00facleo del sistema operativo invitado para que pueda interactuar con el hipervisor a trav\u00e9s de esta API. Pero normalmente esto se resuelve instalando controladores especiales en el sistema operativo invitado. En KVM, esta API se llama <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/developerworks\/library\/l-virtio\/index.html\">virtio API<\/a><\/noindex>.<\/p>\n<p>Con la paravirtualizaci\u00f3n, en comparaci\u00f3n con la traducci\u00f3n, el camino hacia el dispositivo f\u00edsico se acorta significativamente al enviar comandos directamente desde la m\u00e1quina virtual al proceso del hipervisor en el host. Esto permite acelerar la ejecuci\u00f3n de todas las instrucciones dentro de la m\u00e1quina virtual. En KVM, esto es responsabilidad de la API de virtio, que solo funciona para ciertos dispositivos, como adaptadores de red o de disco. Es por eso que dentro de las m\u00e1quinas virtuales se instalan controladores virtio. <\/p>\n<p>El lado negativo de tal aceleraci\u00f3n es que no todos los procesos que se ejecutan dentro de la m\u00e1quina virtual permanecen dentro de ella. Esto crea ciertos efectos especiales que pueden resultar en la aparici\u00f3n en steal. Recomiendo comenzar un estudio detallado de esta cuesti\u00f3n con <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/239238\/\">Una API para I\/O virtual: virtio<\/a><\/noindex>.<\/p>\n<h3>2.3. Programaci\u00f3n \u00abjusta\u00bb<\/h3>\n<p>\nUna m\u00e1quina virtual en un hipervisor es, de hecho, un proceso habitual que se rige por las leyes de programaci\u00f3n (distribuci\u00f3n de recursos entre procesos) en el n\u00facleo de Linux, por lo que lo examinaremos m\u00e1s a fondo. <\/p>\n<p>En Linux se utiliza el llamado CFS, Completely Fair Scheduler, que a partir del n\u00facleo 2.6.23 se convirti\u00f3 en el planificador por defecto. Para entender este algoritmo, se puede leer Linux Kernel Architecture o los fuentes. La esencia del CFS reside en distribuir el tiempo de CPU entre los procesos en funci\u00f3n de la duraci\u00f3n de su ejecuci\u00f3n. Cuanto m\u00e1s tiempo de CPU requiera un proceso, menos tiempo recibir\u00e1. Esto garantiza la ejecuci\u00f3n \u00abjusta\u00bb de todos los procesos, evitando que un proceso monopolice constantemente todos los procesadores y permitiendo que otros tambi\u00e9n puedan ejecutarse. <\/p>\n<p>A veces, esta par\u00e1bola conduce a artefactos interesantes. Los antiguos usuarios de Linux seguramente recordar\u00e1n el congelamiento de editores de texto comunes en el escritorio durante el lanzamiento de aplicaciones que consumen muchos recursos, como compiladores. Esto ocurr\u00eda porque las tareas no intensivas en recursos de las aplicaciones de escritorio compet\u00edan con tareas que consum\u00edan activamente recursos, como el compilador. El CFS considera que esto es injusto, por lo que detiene peri\u00f3dicamente el editor de texto y permite que la CPU procese las tareas del compilador. Esto se corrigi\u00f3 mediante el mecanismo <noindex><a rel=\"nofollow\" href=\"https:\/\/marc.info\/?l=linux-kernel&amp;m=128978361700898\">sched_autogroup<\/a><\/noindex>, pero a\u00fan quedan muchas otras particularidades en la distribuci\u00f3n del tiempo de CPU entre las tareas. En realidad, esta no es una historia sobre lo mal que est\u00e1 el CFS, sino un intento de llamar la atenci\u00f3n sobre que la distribuci\u00f3n \u00abjusta\u00bb del tiempo de CPU no es una tarea trivial.<\/p>\n<p>Otro punto importante en el planificador es la preemption. Esto es necesario para expulsar un proceso que ha consumido demasiado tiempo de CPU y permitir que otros procesos trabajen. El proceso de expulsi\u00f3n se llama cambio de contexto, o context switching. Durante este proceso, se guarda todo el contexto de la tarea: el estado de la pila, los registros y otros, despu\u00e9s de lo cual el proceso es enviado a esperar y otro ocupa su lugar. Esta es una operaci\u00f3n costosa para el sistema operativo y se utiliza raramente, pero en esencia no es algo negativo. Un cambio frecuente de contexto puede indicar un problema en el sistema operativo, pero normalmente ocurre de manera continua sin se\u00f1alar nada en particular.<\/p>\n<p>Este extenso relato es necesario para explicar un hecho: cuanto m\u00e1s recursos de CPU intenta consumir un proceso en un planificador honesto de Linux, m\u00e1s r\u00e1pido ser\u00e1 detenido para que otros procesos tambi\u00e9n puedan trabajar. Si esto es correcto o no es una pregunta complicada que se responde de diferentes maneras seg\u00fan la carga. Hasta hace poco, el planificador en Windows estaba orientado a dar prioridad al procesamiento de aplicaciones de escritorio, lo que pod\u00eda hacer que los procesos en segundo plano se congelaran. En Sun Solaris hab\u00eda cinco clases de planificadores diferentes. Cuando se introdujo la virtualizaci\u00f3n, se agreg\u00f3 una sexta, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opennet.ru\/man.shtml?topic=FSS&amp;category=7&amp;russian=4\">planificador de participaci\u00f3n justa<\/a><\/noindex>, porque los cinco anteriores no funcionaban adecuadamente con la virtualizaci\u00f3n de Solaris Zones. Recomiendo comenzar un estudio detallado sobre este tema con libros como <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. \u00bfC\u00f3mo monitorear el steal?<\/h3>\n<p>\nMonitorear el steal dentro de una m\u00e1quina virtual, al igual que cualquier otra m\u00e9trica del procesador, es sencillo: se puede utilizar cualquier herramienta de recolecci\u00f3n de m\u00e9tricas de CPU. Lo principal es que la m\u00e1quina virtual est\u00e9 en Linux. Windows, por alguna raz\u00f3n, no proporciona esta informaci\u00f3n a sus usuarios. \ud83d\ude41<\/p>\n<p><img decoding=\"async\" alt=\"Steal: qui\u00e9n roba tiempo de CPU en las m\u00e1quinas virtuales\" src=\"\/wp-content\/uploads\/2019\/04\/3c7cd04f73fd6a74b86af81382090b69.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Salida del comando top: detalle de la carga de la CPU, en la columna m\u00e1s a la derecha \u2014 steal<\/i><\/p>\n<p>La dificultad surge al intentar obtener esta informaci\u00f3n desde el hipervisor. Se puede tratar de predecir el steal en la m\u00e1quina host, por ejemplo, seg\u00fan el par\u00e1metro Load Average (LA) \u2014 el valor promedio de procesos esperando en cola para ser ejecutados. La metodolog\u00eda para calcular este par\u00e1metro no es sencilla, pero en general, si el LA normalizado por la cantidad de hilos del procesador es mayor a 1, esto indica que el servidor con Linux est\u00e1 sobrecargado por alguna raz\u00f3n. <\/p>\n<p>\u00bfQu\u00e9 est\u00e1n esperando todos estos procesos? La respuesta obvia es el procesador. Pero la respuesta no es del todo correcta, porque a veces el procesador est\u00e1 libre y la LA est\u00e1 disparada. Recuerden, <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/911976\/redhat-nfs-cluster-high-load-average-suddenly\">c\u00f3mo se desconecta el NFS y c\u00f3mo aumenta la LA<\/a><\/noindex>. De manera similar, esto puede ocurrir con el disco y otros dispositivos de entrada\/salida. Sin embargo, en realidad, los procesos pueden esperar la finalizaci\u00f3n de cualquier tipo de bloqueo, tanto f\u00edsico, relacionado con el dispositivo de entrada\/salida, como l\u00f3gico, por ejemplo, un mutex. Esto tambi\u00e9n incluye bloqueos a nivel de hardware (como la misma respuesta del disco) o de l\u00f3gica (los llamados primitivos de bloqueo, que abarcan numerosas entidades como mutex adaptativos y de espera, sem\u00e1foros, variables de condici\u00f3n, bloqueos de lectura\/escritura, bloqueos IPC\u2026)<\/p>\n<p>Otra peculiaridad de la LA es que se considera como un valor promedio por el sistema operativo. Por ejemplo, 100 procesos compiten por un archivo, y entonces LA=50. Un valor tan alto parecer\u00eda indicar que el sistema operativo est\u00e1 en problemas. Pero para un c\u00f3digo mal escrito puede ser un estado normal, donde solo \u00e9l tiene problemas, mientras que otros procesos en el sistema operativo no sufren. <\/p>\n<p>Debido a este promediado (que ocurre en un per\u00edodo de no menos de un minuto), determinar algo a partir del indicador LA no es una tarea agradecida, con resultados bastante indefinidos en casos concretos. Si intentan investigar, notar\u00e1n que en los art\u00edculos de Wikipedia y otros recursos disponibles solo se describen los casos m\u00e1s simples, sin una explicaci\u00f3n profunda del proceso. A todos los interesados los remito, nuevamente, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-08-08\/linux-load-averages.html\">aqu\u00ed, a Brendan Gregg<\/a><\/noindex> \u00a0\u2014 a trav\u00e9s de los enlaces. Para quienes no quieren leer en ingl\u00e9s \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/335326\/\">la traducci\u00f3n de su popular art\u00edculo sobre LA<\/a><\/noindex>.<\/p>\n<h2>3. Efectos especiales<\/h2>\n<p>\nAhora nos detendremos en los casos principales de aparici\u00f3n de steal, con los que nos hemos encontrado. Les contar\u00e9 c\u00f3mo se derivan de todo lo anterior y c\u00f3mo se relacionan con los indicadores en el hipervisor.<\/p>\n<p><b>Reutilizaci\u00f3n<\/b>. Lo m\u00e1s simple y com\u00fan: el hipervisor est\u00e1 sobreutilizado. De hecho, hay muchas m\u00e1quinas virtuales en ejecuci\u00f3n, un alto consumo de CPU dentro de ellas, una gran competencia, reutilizaci\u00f3n por LA superior a 1 (en relaci\u00f3n a los hilos de CPU). Dentro de todas las m\u00e1quinas virtuales, todo se ralentiza. El steal, transmitido desde el hipervisor, tambi\u00e9n aumenta, se debe redistribuir la carga o apagar a alguien. En general, tiene sentido y es entendible.<\/p>\n<p><b>Paravirtualizaci\u00f3n contra instancias solitarias<\/b>. En el hipervisor hay una \u00fanica m\u00e1quina virtual, que consume una peque\u00f1a parte de su capacidad, pero genera una gran carga de entrada\/salida, por ejemplo, en disco. Y de alguna manera, aparece un peque\u00f1o steal, hasta el 10% (como muestran varios experimentos realizados).<\/p>\n<p>Es un caso interesante. El steal aparece aqu\u00ed precisamente debido a bloqueos a nivel de controladores paravirtualizados. Dentro de la m\u00e1quina virtual se genera una interrupci\u00f3n, que es procesada por el controlador y enviada al hipervisor. Debido al procesamiento de la interrupci\u00f3n en el hipervisor, para la m\u00e1quina virtual esto parece una solicitud enviada, est\u00e1 lista para ejecutar y espera el procesador, pero no se le proporciona tiempo de CPU. La m\u00e1quina virtual piensa que ese tiempo ha sido robado. <\/p>\n<p>Esto ocurre en el momento de enviar el b\u00fafer, que se env\u00eda al espacio del kernel del hipervisor, y comenzamos a esperarlo. Sin embargo, desde el punto de vista de la m\u00e1quina virtual, deber\u00eda regresar de inmediato. Por lo tanto, de acuerdo con el algoritmo de c\u00e1lculo del steal, este tiempo se considera robado. Probablemente, en esta situaci\u00f3n pueden existir otros mecanismos (como el procesamiento de algunas llamadas al sistema), pero no deber\u00edan diferir mucho.<\/p>\n<p><b>El programador contra las m\u00e1quinas virtuales de alta carga<\/b>. Cuando una m\u00e1quina virtual sufre m\u00e1s steal que otras, est\u00e1 relacionado precisamente con el programador. Cuanto m\u00e1s intensa sea la carga del procesador, m\u00e1s r\u00e1pido el programador la expulsar\u00e1 para que las dem\u00e1s tambi\u00e9n puedan trabajar. Si la m\u00e1quina virtual consume poco, casi no notar\u00e1 steal: su proceso est\u00e1 honestamente sentado y esperando, hay que darle m\u00e1s tiempo. Si la m\u00e1quina virtual produce una carga m\u00e1xima en todos sus n\u00facleos, con mayor frecuencia es expulsada del procesador y se intenta no darle mucho tiempo. <\/p>\n<p>Es a\u00fan peor cuando los procesos dentro de la m\u00e1quina virtual intentan obtener m\u00e1s CPU porque no pueden manejar el procesamiento de datos. Entonces, el sistema operativo en el hipervisor, a trav\u00e9s de una optimizaci\u00f3n honesta, comenzar\u00e1 a dar cada vez menos tiempo de CPU. Este proceso ocurre de manera avalancha, y el steal se dispara por las nubes, aunque las otras m\u00e1quinas virtuales pueden no notarlo casi en absoluto. Y cuanto m\u00e1s n\u00facleos, peor ser\u00e1 para la m\u00e1quina que est\u00e1 sufriendo. En resumen, las m\u00e1quinas virtuales de alta carga con muchos n\u00facleos son las que m\u00e1s sufren.<\/p>\n<p><b>Bajo LA, pero hay steal<\/b>. Si LA es aproximadamente 0,7 (es decir, el hipervisor parece estar subutilizado), pero dentro de algunas m\u00e1quinas virtuales se observa steal:<\/p>\n<ul>\n<li>La opci\u00f3n que ya se ha descrito anteriormente con para-virtualizaci\u00f3n. La m\u00e1quina virtual puede recibir m\u00e9tricas que indican el steal, aunque el hipervisor est\u00e9 funcionando bien. Seg\u00fan los resultados de nuestros experimentos, dicho steal no supera el 10 % y no deber\u00eda afectar significativamente el rendimiento de las aplicaciones dentro de la m\u00e1quina virtual.\n<\/li>\n<li>Se considera incorrectamente el par\u00e1metro LA. M\u00e1s precisamente, en cada momento espec\u00edfico se calcula correctamente, pero al promediar durante un minuto el resultado queda subestimado. Por ejemplo, si una m\u00e1quina virtual utiliza todos sus procesadores durante exactamente medio minuto, el LA durante un minuto en el hipervisor ser\u00e1 0.15; cuatro m\u00e1quinas virtuales, funcionando al mismo tiempo, dar\u00e1n 0.6. Y el hecho de que durante medio minuto cada una de ellas experiment\u00f3 un alto steal de hasta el 25 % en el indicador LA ya no se puede rescatar.\n<\/li>\n<li>De nuevo, debido al planificador, que decidi\u00f3 que alguien est\u00e1 consumiendo demasiado, y que esa persona espere. Mientras tanto, cambio de contexto, manejo interrupciones y me ocupo de otras cosas importantes del sistema. Como resultado, algunas m\u00e1quinas virtuales no ven problemas, mientras que otras experimentan una grave degradaci\u00f3n del rendimiento.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>4. Otras distorsiones<\/h2>\n<p>\nHay millones de razones m\u00e1s para las distorsiones en la entrega justa del tiempo de CPU en una m\u00e1quina virtual. Por ejemplo, las complicaciones en los c\u00e1lculos son causadas por el hyper-threading y NUMA. Estos complican finalmente la elecci\u00f3n del n\u00facleo para la ejecuci\u00f3n del proceso, porque el planificador utiliza coeficientes: pesos que al cambiar de contexto hacen que el conteo sea a\u00fan m\u00e1s complicado.<\/p>\n<p>Puede haber distorsiones debido a tecnolog\u00edas como el turbo-boost o, por el contrario, el modo de ahorro de energ\u00eda, que al contabilizar la utilizaci\u00f3n pueden aumentar o disminuir artificialmente la frecuencia o incluso el cu\u00e1ntum de tiempo en el servidor. La activaci\u00f3n del turbo-boost reduce el rendimiento de un hilo de procesador debido al aumento del rendimiento de otro. En ese momento, la informaci\u00f3n sobre la frecuencia actual del procesador no se transmite a la m\u00e1quina virtual, y ella cree que su tiempo est\u00e1 siendo robado (por ejemplo, solicit\u00f3 2 GHz, pero recibi\u00f3 la mitad). <\/p>\n<p>En general, pueden haber muchas razones para las distorsiones. En un sistema espec\u00edfico puedes descubrir algo m\u00e1s. Es mejor empezar con los libros a los que he enlazado anteriormente y la recopilaci\u00f3n de estad\u00edsticas del hipervisor con utilidades como perf, sysdig, systemtap, de las cuales hay <noindex><a rel=\"nofollow\" href=\"https:\/\/jvns.ca\/blog\/2017\/07\/05\/linux-tracing-systems\/\">docenas<\/a><\/noindex>.<\/p>\n<h2>5. Conclusiones<\/h2>\n<p><\/p>\n<ol>\n<li>Una cierta cantidad de steal puede surgir debido a la paravirtualizaci\u00f3n, y se puede considerar normal. En internet se menciona que este valor puede ser del 5-10%. Depende de las aplicaciones dentro de la m\u00e1quina virtual y de la carga que estas generen en sus dispositivos f\u00edsicos. Aqu\u00ed es importante prestar atenci\u00f3n a c\u00f3mo se comportan las aplicaciones dentro de las m\u00e1quinas virtuales.\n<\/li>\n<li>La relaci\u00f3n entre la carga en el hipervisor y el steal dentro de la m\u00e1quina virtual no siempre est\u00e1 claramente interrelacionada; ambas estimaciones de steal pueden ser err\u00f3neas en situaciones espec\u00edficas bajo diferentes cargas.\n<\/li>\n<li>El planificador tiene una mala disposici\u00f3n hacia los procesos que piden mucho. Intenta dar menos a quienes piden m\u00e1s. Las grandes m\u00e1quinas virtuales son un problema.\n<\/li>\n<li>Un peque\u00f1o steal puede ser normal incluso sin paravirtualizaci\u00f3n (teniendo en cuenta la carga dentro de la m\u00e1quina virtual, las caracter\u00edsticas de la carga de los vecinos, la distribuci\u00f3n de la carga entre hilos y otros factores).\n<\/li>\n<li>Si quieres averiguar el steal en un sistema espec\u00edfico, debes investigar varias opciones, recopilar m\u00e9tricas, analizarlas cuidadosamente y pensar en c\u00f3mo distribuir la carga de manera uniforme. De cualquier caso pueden surgir variaciones que es necesario confirmar experimentalmente o ver en el depurador del n\u00facleo.\n<\/li>\n<\/ol>\n<p>Fuente: <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\/es\/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=\"es_ES\" \/>\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\/es\/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: qui\u00e9n roba tiempo de CPU a las m\u00e1quinas virtuales | ProHoster","description":"\u00a1Hola!","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/32331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=32331"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/32331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/24147"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=32331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=32331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=32331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}